perm filename CLCLEA.MSG[COM,LSP]1 blob
sn#840215 filedate 1987-05-19 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂23-Apr-87 1359 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue DEFVAR-INIT-TIME (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 13:59:21 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123216; Thu 23-Apr-87 16:59:34 EDT
Date: Thu, 23 Apr 87 16:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue DEFVAR-INIT-TIME (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870423165916.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: DEFVAR-INIT-TIME
References: DEFVAR (p68)
Category: CLARIFICATION
Edit history: 23-Apr-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The description of DEFVAR is not completely clear about the time at
which the initialization occurs.
On p68 it says ``VARIABLE is initialized to the result of evaluating
the form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE
form is not evaluated unless it is used; this fact is useful if
evaluation of the INITIAL-VALUE form does something expensive like
create a large data structure.''
Although I think the original CL designers all knew what this wording
was intended to mean, I have discovered people who have misinterpreted
the "unless it is used" to mean "unless the variable is used" rather
than "unless the initial-value is to be used". The problem is that the
"it" is ambiguous.
Having made this false assumption, the people I talked to thought --
and understandably (if lamentably) so -- that they wouldn't know if
the variable was to be used until the code ran, so they had the model
that the intention was to provide a kind of lazy initialization that
happened upon the variable's first unbound reference. This confusion
appears to have been further supported by the additional verbiage about
not creating expensive structures that are not needed.
Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):
Clarify that the evaluation of the initial value and the initialization
happen at DEFVAR execution time (if at all).
Rationale:
I think it was clear at design time that this was intended. The manual
should therefore be clear.
Current Practice:
Nearly all implementations implement the proposed interpretation.
Adoption Cost:
The misinterpretation is much harder to implement than the proposed
interpretation. Adoption of the changes should be straightforward.
Benefits:
This clarification makes the semantics of an important primitive
more well-defined.
Conversion Cost:
Most users presumably expect the behavior currently in practice in most
dialects. There's not a lot of code where the difference comes into play
anyway. Presumably the conversion cost is fairly trivial.
Aesthetics:
Being a clarification, this really doesn't have much aesthetic effect.
Discussion:
KMP thinks this clarification is important.
∂23-Apr-87 1432 gls@Think.COM AREF-1D
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 23 Apr 87 14:32:25 PDT
Received: from johannes-scotus-erigena by Think.COM via CHAOS; Thu, 23 Apr 87 16:36:10 EST
Date: Thu, 23 Apr 87 17:33 EDT
From: Guy Steele <gls@Think.COM>
Subject: AREF-1D
To: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870422164300.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870423173318.9.GLS@JOHN-THE-SCOT.THINK.COM>
Note that I had proposed something like this to be called
AREF-ROW-MAJOR-ORDER. It may be that that proposal had
some relevant material that KMP might want to take into account.
Then again, maybe he already did. That name is too long,
but I feel that the row-majorness should be part of the name.
How about ROW-MAJOR-AREF? But I don't feel strongly about it.
Otherwise I support the proposal.
Ah. I recall that perhaps I had suggested having also
a function ROW-MAJOR-INDEX that takes an array and a bunch
of subscripts, just like AREF, and returns the row-major
index of that element.
--Guy
∂23-Apr-87 1447 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue GC-MESSAGES (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 14:47:28 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123309; Thu 23-Apr-87 17:46:56 EDT
Date: Thu, 23 Apr 87 17:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870423174645.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: GC-MESSAGES
References: None
Category: ENHANCEMENT
Edit history: 23-Apr-87, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Although there is no standard interface to the garbage collector,
it is common for there to be a garbage collector in nearly every system.
In many systems, these do unsolicited typeout which obstructs program
typeout in unpredictable ways.
Proposal (GC-MESSAGES:FLAG-VARIABLE):
Make a variable called *GC-MESSAGES* which controls GC message typeout.
Possible values of this stream include:
T Standard notifications (typically to *TERMINAL-IO*).
NIL No notifications.
Since not all implementations could allow an arbitrary user-supplied
stream for use as a value of *GC-MESSAGES* (because streams might cons
and consing might be illegal at the time of the message), this cannot
be offered as an option. However, this would be a reasonable
implementation-dependent extension in some systems, so we should offer
it as an option.
In multi-processed, shared-address space implementations, if the GC is
going to type a message on a stream that belongs to some other process
(or otherwise ``notify'' the process, to use Lisp Machine terminology),
the value of *GC-MESSAGES* in the process being notified should be used
rather than the value in the current process so that this variable can
be usefully bound by user programs.
Permit that as an act of desperation, shortly before running completely
out of space when *GC-MESSAGES* is NIL, the GC may notify the user
that he is about to lose (in spite of the fact that he has seemingly
asked to lose). This permission is important so that people don't feel
afraid to bind *GC-MESSAGES* to NIL to suppress frequent messages
only for fear that they might not get critical last minute information
that says it's time to do drastic cleanup action.
Rationale:
Application programs which do display (especially display which conses)
need a way of deferring GC warnings that might ruin the display.
Current Practice:
This functionality is provided in some form or another by a number of
implementations.
Zetalisp currently offers SI:GC-REPORT-STREAM which can be set to T, NIL,
or a stream. It provides useful flexibility and is used by quite a number
of users.
Other systems provide ways of enabling or disabling the messages, or of
customizing the message which is typed out.
Adoption Cost:
The set of places in which the GC does typeout is probably very
restricted, so finding them and changing them to be appropriately
conditionalized is probably not a lot of work.
Benefits:
This would allow the user some portable control over a common feature which
cannot currently be controlled in a portable way.
Conversion Cost:
This is an upward compatible change.
Aesthetics:
No significant impact.
Discussion:
MACSYMA needs this (so it can bind it to NIL). Its display often does
consing. In some implementations this can cause a GC, which can in turn
spoil the carefully crafted display.
∂23-Apr-87 1453 Moon@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 14:53:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123312; Thu 23-Apr-87 17:50:35 EDT
Date: Thu, 23 Apr 87 17:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: Guy Steele <gls@Think.COM>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: <870423173318.9.GLS@JOHN-THE-SCOT.THINK.COM>
Message-ID: <870423175014.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 23 Apr 87 17:33 EDT
From: Guy Steele <gls@Think.COM>
Note that I had proposed something like this to be called
AREF-ROW-MAJOR-ORDER. It may be that that proposal had
some relevant material that KMP might want to take into account.
Then again, maybe he already did. That name is too long,
but I feel that the row-majorness should be part of the name.
How about ROW-MAJOR-AREF? But I don't feel strongly about it.
Otherwise I support the proposal.
row-major-aref or aref-row-major would be good names. I think
KMP's suggested function is sufficiently specialized that it does
not need an especially short name.
Ah. I recall that perhaps I had suggested having also
a function ROW-MAJOR-INDEX that takes an array and a bunch
of subscripts, just like AREF, and returns the row-major
index of that element.
array-row-major-index is already in the language.
∂23-Apr-87 2031 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue GC-MESSAGES (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 20:31:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123639; Thu 23-Apr-87 23:31:18 EDT
Date: Thu, 23 Apr 87 23:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870423174645.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870423233110.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
This seems a little short-sighted. GC messages aren't necessarily the
only unsolicited messages. In the example application you gave, there
is no reason to treat GC messages differently from other messages.
Also, a simple on/off switch may be a bit too simple. Not all systems
have windows, but for the ones that do a three-state switch could be
defined in an implementation-independent way: (1) turn the messages off,
(2) put them in the typescript, (3) make them visible to the user in a
way that doesn't interfere with the typescript. Even some
teletype-oriented systems are able to implement option 3.
In some systems it may not be possible to implement this with a variable,
since changing the state of the switch may have to communicate with an
operating system written in some horrible language. The safest thing would
be a macro, whose expansion is system-dependent, and within the dynamic
extent of the macro's body unsolicited messages are controlled.
I'm not very optimistic about the possibility of standardizing on this kind
of environmental issue, but perhaps some very simple facility to prevent
messing up of the screen can be agreed on.
∂23-Apr-87 2150 Moon@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 21:50:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123691; Fri 24-Apr-87 00:49:23 EDT
Date: Fri, 24 Apr 87 00:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: CL-Cleanup@sail.stanford.edu
cc: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
In-Reply-To: <870423123259.1.HORNIG@WINTER.SCRC.Symbolics.COM>
Message-ID: <870424004910.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here's an opinion on this issue from one of our developers, with an
interesting rationale. I agree with the rationale, which is why I
support either the mentioned proposal or the one that signals an error
and allows the outer THROW to be completed from the debugger.
Date: Thu, 23 Apr 87 12:32 EDT
From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
I found KMP's proposal for this and I can now comment effectively. My
personal feelings are that the right proposal for 1 is the one below. I
agree with KMP that 2C is correct for 2.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1?):
Some may believe that the throw to BAR is suppressed,
the THROW to FOO should somehow complete, but that XXX would
never be printed.
The important factor here is that I believe that whenever there are two
THROW's in competition, that we should always proceed to the outermost
CATCH. This rule permits a programmer to assume that if he does a THROW
out of a computation that that computation will be exited, one way or
another. This is related to Moon's comment about the programming
environment and aborting.
∂23-Apr-87 2157 Moon@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 21:57:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123694; Fri 24-Apr-87 00:57:35 EDT
Date: Fri, 24 Apr 87 00:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870422165116.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870424005727.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
The wording of your proposal is such that it implies that implementations
that ignore the :ADJUSTABLE argument and simply make all arrays adjustable
would no longer be valid. I doubt that you intended this. Implementations
should not be required to implement the non-adjustability complexity if
they don't need it.
Your comment about dead arrays is too obscure.
Having ADJUST-ARRAY sometimes adjust the original array and sometimes
make a copy is dangerous. I suppose it's no more dangerous than
NREVERSE and SORT, but we know that programmers from all walks of life
consistently have trouble using NREVERSE and SORT correctly. I'd like
to see some thought given to improving the proposal to make it less
dangerous.
∂23-Apr-87 2209 edsel!bhopal!jonl@navajo.stanford.edu AREF-1D
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 22:09:05 PDT
Received: by navajo.stanford.edu; Thu, 23 Apr 87 21:08:20 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA25436; Thu, 23 Apr 87 20:39:17 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA06857; Thu, 23 Apr 87 21:36:52 PDT
Date: Thu, 23 Apr 87 21:36:52 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704240436.AA06857@bhopal.edsel.com>
To: navajo!gls%Think.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%sail@navajo.stanford.edu
In-Reply-To: Guy Steele's message of Thu, 23 Apr 87 17:33 EDT
Subject: AREF-1D
Your "clarifications" of 6-Dec-85 (distributed at the Boston Meeting
of what eventually became X3J13) added a function named ROW-MAJOR-AREF.
Since CLtL already specified ARRAY-ROW-MAJOR-INDEX, this addition seemed
very natural and "called for". So Lucid Common Lisp has had it available
since shortly thereafter.
-- JonL --
∂23-Apr-87 2255 KMP@STONY-BROOK.SCRC.Symbolics.COM AREF-1D
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 22:52:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123714; Fri 24-Apr-87 01:52:42 EDT
Date: Fri, 24 Apr 87 01:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8704240436.AA06857@bhopal.edsel.com>
Message-ID: <870424015232.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The reason for the name clash is that I wasn't looking at Steele's
corrections list at the time I generated the proposal. It was on an
independent list of Macsyma-related issues of my own. Sorry for the
confusion.
The fact that the row-major feature is built into more functions than
just those which have the phrase "ROW-MAJOR" in them (eg, displaced
arrays) leads me to believe that the phrase ROW-MAJOR is just redundant.
Also, I don't like the phrase "ROW-MAJOR" because it feels very 2d
because the term row seems to apply to 2d matrices. I know it's got a
perfectly well-defined way of generalizing, but...
Also, I thought a name with "1D" in it would emphasize that this was
a non-standard access. I guess "ROW-MAJOR" does that, too, though.
In any case, although I did have reasons for the choice of name, I'm
not passionate about them. Since there's already a precedent for the
other name, I'm happy to go with that. ROW-MAJOR-AREF is fine.
By the way, I think an inverse to ARRAY-ROW-MAJOR-INDEX might nicely
round out the set of operations which took an offset and either a list
of dimensions or an array and returned the standard reference pattern
might nicely round out the set of operations in this family...
∂24-Apr-87 1326 masinter.PA@Xerox.COM Re: Issue DEFVAR-INIT-TIME (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87 13:26:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 APR 87 13:17:43 PDT
From: masinter.PA@Xerox.COM
Date: 24 Apr 87 13:17:31 PDT
Subject: Re: Issue DEFVAR-INIT-TIME (Version 1)
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Thu, 23 Apr
87 16:59 EDT, <870423165916.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870424-131743-2546@Xerox>
Kent,
Perhaps you could hold off submitting more issues until we get some of
the open ones out of the way?
∂24-Apr-87 1846 edsel!bhopal!jonl@navajo.stanford.edu ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Apr 87 18:46:54 PDT
Received: by navajo.stanford.edu; Fri, 24 Apr 87 17:46:11 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA29466; Fri, 24 Apr 87 17:09:51 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA07893; Fri, 24 Apr 87 18:07:26 PDT
Date: Fri, 24 Apr 87 18:07:26 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704250107.AA07893@bhopal.edsel.com>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 24 Apr 87 00:57 EDT
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
The complexity of this discussion about adjust-array makes me wonder
if this function isn't striving for too much generality. Virtually all
usages I've seen or heard of are really for adjust-array-size. KMP's
proposal sounds like he's trying to avoid simply makeing a new array and
copying (after some fashion) the old into the new. Maybe it's a simpler
language design not to try to cover every possible base, but to provide the
primitives that permit end-users to "roll their own". In line with
your remarks:
Having ADJUST-ARRAY sometimes adjust the original array and sometimes
make a copy is dangerous. I suppose it's no more dangerous than
NREVERSE and SORT, but we know that programmers from all walks of life
consistently have trouble using NREVERSE and SORT correctly. I'd like
to see some thought given to improving the proposal to make it less
dangerous.
How about the following simplification for adjust-array:
(1) a new function shall be added which will copy parts of the contents
of one array into another; MacLisp's FILLARRAY is a base-level start
for such a function, but one would like something for multi-dimensional
arrays that is more meaningful than simple linear, row-wise fill.
(2) adjust array will only "mess" with the size (or dimensions) and with
the displacement (i.e., to a new target array, or new index-offset).
Fill-pointers can already be modified with setf. Getting new contents
into a displaced, "adjusted" array can be done by first calling the
function ARRAY-DISPLACED-P (as specified in GLS's "clarifications" of
6-Dec-85) and then using the function called for in (1) to copy parts
of the original displaced-to array into the newly-displaced one.
-- JonL --
∂25-Apr-87 0021 gls@think.com DELETE, SORT, ADJUST-ARRAY considered harmful
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Apr 87 00:21:31 PDT
Received: by Think.COM; Sat, 25 Apr 87 02:25:34 EST
Date: Sat, 25 Apr 87 02:25:34 EST
From: Guy Steele <gls@think.com>
Message-Id: <8704250725.AA21198@Think.COM>
To: cl-cleanup@sail.stanford.edu
Subject: DELETE, SORT, ADJUST-ARRAY considered harmful
Here is an idea that is only two-thirds whimsical: since 90% of all
people who use DELETE, SORT, etc. lose because they fail to put a setq
around it (as in (SETQ X (DELETE ITEM X)), etc.), why not make it
impossible for them to lose? Remove these primitives from the language,
and introduce their inverses as SETF places. For example, instead of
writing (SORT BREAKFAST) or (SETF X (SORT BREAKFAST)), write
(SETF (SCRAMBLE X) BREAKFAST)
; that is, the variable X is changed so as to make the value of
BREAKFAST a scrambled version of it. SCRAMBLE would not be a function
itself; you could use it only within a SETF, thereby guaranteeing you
don't lose. Similarly (SETF (UNDELETE ITEM Z) Z),
(SETF (UNADJUST-ARRAY Z) Z), and so on.
Well, maybe the proposed syntax stinks, but perhaps some way of
idiot-proofing destructive operations should nevertheless be found.
--Yours for a safer language,
Quux
P.S. I thought you'd never ask: haven't you ever had
scrambled X for breakfast?
∂27-Apr-87 1151 Masinter.pa@Xerox.COM Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Apr 87 11:51:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 APR 87 11:43:07 PDT
Date: 27 Apr 87 11:51 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Thu, 23 Apr 87 17:50 EDT
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870427-114307-1095@Xerox>
How does this (new) proposal relate to the (old) proposal by Touretsky?
I'm uncomfortable leaving SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS unfinished
while going ahead with a separate proposal which seems to relate to
similar concerns.
Comments?
∂27-Apr-87 1312 Masinter.pa@Xerox.COM status
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Apr 87 13:12:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 APR 87 13:07:08 PDT
Date: 27 Apr 87 13:15 PDT
From: Masinter.pa@Xerox.COM
Subject: status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870427-130708-1239@Xerox>
This is my status file. Please mail any corrections you have.
I don't think we've made very good progress. The only issue that I've
seen resolution on since our meeting before X3J13 is
FLET-IMPLICIT-BLOCK.
I think we can re-release COMPILER-WARNING-STREAM ( Version 3),
DEFVAR-INITIALIZATION (Version 3), FORMAT-ATSIGN-COLON (Revision 3),
IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
I think we are near completion on these, but they need writing work
*SOON*:
DEFVAR-INIT-TIME, DO-SYMBOLS-DUPLICATES (Revision 1),
GET-SETF-METHOD-ENVIRONMENT, FORMAT-OP-C (revision 1), FUNCTION-TYPE
(revision 2), IF-BODY (Version 4), KEYWORD-ARGUMENT-NAME-PACKAGE
(Version 1), PRINC-CHARACTER:WRITE-CHAR
The rest seem further from general agreement of the form of the
proposal.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ADJUST-ARRAY-NOT-ADJUSTABLE
Submitted by KMP 22-Apr-87
comment from Moon, JonL 24-Apr
ADJUST-ARRAY-DISPLACEMENT (revision 1)
Revision 1 by SEF, 18-Apr-87
Comment by Moon 21 Apr 87
AREF-1D
Submitted 22-Apr-87 by KMP
Discussion about name of function, addition of ROW-MAJOR-INDEX
function, etc.
ROW-MAJOR-AREF in clarifications
ASSOC-RASSOC-IF-KEY
Submitted 22-Apr-87 by KMP
COMPILER-WARNING-BREAK (revision 2)
not Released.
Questions on interaction with condition proposal.
remailed 7-apr-87
SEF suggested KMP should work on.
COMPILER-WARNING-STREAM (Revision 4)
Rev 3 was released
Version 4, submittted by SEF
Decided to revert to previous version,
consider DRIBBLE as a separate item.
Need to add DRIBBLE note in Discussion.
DEFVAR-INITIALIZATION (Revision 3)
Released
remailed 7-apr-87
(final form)
DEFVAR-INIT-TIME
Submitted 23-Apr-87, Version 1 by Pitman
DO-SYMBOLS-DUPLICATES (Revision 1)
mailed 7-apr-87
Revision 1 by SEF 17-apr
Not released, in discussion
Questions "is it really inefficient to require non-duplicates?" Add
more arguments?
ENVIRONMENT-ARGUMENTS (revision 1)
SEF summarized issues 18-Apr
Decided to separate again and:
Approve GET-SETF-METHOD-ENVIRONMENT
drop MACRO-FUNCTION-ENVIRONMENT
("merely adding an optional argument to macro-function is not
enough")
discuss SPECIAL-FORM-SHADOW
FLET-IMPLICIT-BLOCK (Revision 5)
Discussion & agreement on cl-cleanup.
revision by Fahlman, 17-Apr-87 to cl-cleanup
FORMAT-ATSIGN-COLON (Revision 3)
Released.
(final form, mailed 17-Apr-87)
FORMAT-OP-C (revision 1)
Discussed and agreed, final form not yet available
(with Moon's amendment)
Need volunteer.
FUNCTION-TYPE (revision 2)
General agreement on basic proposal.
Wording to be worked out.
Mailed 17-Apr-87
Fahlman volunteered to revise & run by RPG
GC-MESSAGES (version 1)
Submitted by Pitman 23-Apr-87
Discussion "a little short-sighted"?
IF-BODY (Version 4)
General agreement to recommend against.
Final form not yet available.
Version 4 mailed by KMP , 19-Apr-87
KMP to produce a new version which Scott will think is balanced
IGNORE-ERRORS
Discussed and agreed, final form not yet available
(LMM: Some objections, defer to error/signal committee?)
Need volunteer.
IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
Released
Should remove confusing "To further clarify: " which is
about INTERN and not IMPORT.
KEYWORD-ARGUMENT-NAME-PACKAGE (Version 1)
Submitted by Moon 20 Apr 87.
Discussion: justification with examples or reference needed before
releasing to X3J13
"I'm sure you've got a good reason for proposing this,
and I'd like some indication of what it is."
PEEK-CHAR-READ-CHAR-ECHO
Agreed to be controversial
Need volunteer to summarize positions.
PRINC-CHARACTER:WRITE-CHAR
Discussed and agreed, final form not yet available
(write-char choice)
Need volunteer.
PROMPT-FOR
Agreed to be controversial
Need volunteer to summarize positions.
REMF-DESTURCTION-UNSPECIFIED
Not discussed
Need volunteer to check over, lead discussion.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
(Should FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Tabled, a subset which deals with only those functions that
don't work in positions will be separated out.
Need volunteer.
SHARPSIGN-BACKSLASH-BITS
No general agreement (the meeting notes read "we cringed")
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-PACKAGE
Discussed, without general agremenet.
Need volunteer to summarize positions.
TAILP-NIL
Received but not discussed
Need volunteer to lead discussion, summarize positions.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Discussed and agreed at meeting, final form not yet available
Moon forwards Hornig msg pointing some problems 23-Apr-87
∂28-Apr-87 1114 KMP@STONY-BROOK.SCRC.Symbolics.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Apr 87 11:13:54 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126277; Tue 28-Apr-87 14:13:26 EDT
Date: Tue, 28 Apr 87 14:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <12276526020.28.TOURETZKY@C.CS.CMU.EDU>,
<870315-164404-1975@Xerox>
Message-ID: <870428141313.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261), COERCE (p51)
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky
28-Apr-87, Version 2 by Pitman (variations on the theme)
Status: For Internal Discussion
Description:
Common Lisp provides many useful operations on lists and vectors which
don't apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can
REPLACE the contents of one vector with another, but one can't do this
for arrays. One can verify that EVERY element of a vector has some
property, but one can't do this for arrays. And so on.
The programmer who wishes to use arrays instead of vectors must give up
most of the useful tools CLtL provides for manipulating sequences, even
though there is no intuitive reason why operations like FILL, REPLACE,
and EVERY shouldn't work on arrays.
Notes about Voting:
Select one of:
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE (by Touretzky)
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED (by Pitman)
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED (status quo)
[See also notes in the discussion about the possibility of a fourth
way to go if you're not satisfied with any of these.]
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):
Common Lisp already provides a facility called "displaced arrays"
which can be used to overlay one array on top of a portion of another,
even if the two are of different ranks, so that the two share storage.
Emphasize this as a way of explaining the behavior of sequence
functions on arbitrary arrays.
Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa. In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
Modify the definition of MAKE-SEQUENCE to accept array descriptions as
well as vector descriptions.
Extend the definitions of sequence functions that either return their
argument sequences or return non-sequences so that they also allow arrays.
These functions should treat array arguments as vectors displaced to the
array storage (in row-major format). The affected functions are LENGTH,
ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY, NOTEVERY, REDUCE,
SEARCH, MISMATCH, FILL, REPLACE, NSUBSTITUTE, NREVERSE, SORT.
For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42,
and (ELT A 7) should return A[0,1,0]. :START and :END keywords would
be interpreted relative to the vector, as would the results returned
by POSITION and SEARCH.
Extend the definitions of sequence functions whose result should be the
same shape as but not necessarily EQ to some argument. These functions
should deal with array arguments by returning an array of the same
shape. The affected functions are SUBSTITUTE, REVERSE, and MAP.
Expressly forbid arrays as arguments to sequence functions that modify
the number of elements in the array because the shape would be undefined.
These functions are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE,
REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Note that EQUALP does -not- treat arrays as vectors. It is not a
sequence function, and it already has a well-defined behavior for arrays.
To test whether the arrays A and B, of different shapes, have the same
elements, one would write:
(AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).
Rationale:
This proposal would expand rather than interfere with existing practice.
Since displaced arrays are already part of Common Lisp, the cost of the
proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops
every time they want to perform an array operation equivalent to FILL,
REPLACE, REDUCE, etc., or else they can build displaced vectors by
hand and pass them to the sequence functions when necessary.
Adoption Cost:
This would involve a lot of changes to functions, but all of them
presumably minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back
up these proposed changes is already in place.
Note that simply extending COERCE, MAKE-SEQUENCE, LENGTH, ELT, and
the SETF expander for ELT would have the side effect of extending
the remaining functions if they are written in the obvious way.
For example:
(DEFUN SUBSTITUTE (NEW-ITEM OLD-ITEM SEQUENCE &KEY ...)
(LET ((RESULT (MAKE-SEQUENCE (TYPE-OF SEQUENCE))))
(DOTIMES (I (LENGTH SEQUENCE) RESULT)
(SETF (ELT RESULT I)
(IF (EQL (ELT SEQUENCE I) OLD-ITEM)
NEW-ITEM
(ELT SEQUENCE I))))))
Benefits:
Users of arrays do not have to use home-grown utilities to duplicate
functionality already primitively provided to users of arrays. The
sequence functions become useful in a variety of new situations.
Conversion Cost:
This change is `upward compatible.' User code should run unmodified.
Aesthetics:
This proposal extends sequence functions to cover arrays while neatly
avoiding the temptation to turn Common Lisp into a half-baked APL.
Instead of trying to provide a full set of array handling primitives
(which would be needed to take arbitrary k-dimensional slices out of
n-dimensional arrays, or to apply an operator across a specific
dimension of a multidimensional array), it requires just one rule:
treat arrays as displaced vectors.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED):
Common Lisp already provides a facility called "displaced arrays"
which can be used to overlay one array on top of a portion of another,
even if the two are of different ranks, so that the two share storage.
Emphasize this as a way of explaining the behavior of sequence
functions on certain arrays.
Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa. In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
Extend the definitions of sequence functions that either return their
argument sequences, return sequences which are the same shape as their
argument, or return non-sequences so that they also allow arrays iff
their action is conceptually independent of the shape of the array.
The affected functions are COUNT, SOME, EVERY, NOTANY, NOTEVERY,
FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP.
Expressly forbid arrays as arguments to other sequence functions. These
unaffected functions are LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH,
MISMATCH, REVERSE, NREVERSE, SORT, MAP, SUBSEQ, COPY-SEQ, CONCATENATE,
MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Rationale:
This proposal would expand rather than interfere with existing practice.
Since displaced arrays are already part of Common Lisp, the cost of the
proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops
every time they want to perform an array operation equivalent to FILL,
REPLACE, etc., or else they can build displaced vectors by hand and
pass them to the sequence functions when necessary.
This proposal extends certain sequence functions in some interesting
ways without committing us to a theory of how arrays and sequences
relate that everyone may not be happy with right now.
Adoption Cost:
This would involve a lot of changes to functions, but all of them
presumably minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back
up these proposed changes is already in place.
Benefits:
Users of arrays do not have to use home-grown utilities to duplicate
functionality already primitively provided to users of arrays. The
sequence functions become useful in a variety of new situations.
Conversion Cost:
This change is `upward compatible.' User code should run unmodified.
Aesthetics:
This extends certain existing sequence functions to allow arrays
as arguments in a fairly non-controversial way, leaving aside the
larger issue of whether and how to generalize the other sequence
functions.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED):
This is the null proposal for the sake of voting clarity. Vote for this
if you think things should not change.
Current Practice:
Neither SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE nor
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED are likely to be implemented
anywhere since they are only very recently proposed.
Discussion:
Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE.
He's been building displaced vectors to pass to sequence functions when
necessary and really dislikes it.
The members of the Cleanup committee expressed interest in the ideas
behind this proposal but weren't sure they could accept it in the
proposed form. A rewrite to separate some of the issues more clearly
was solicited.
Rees suggested that if people are not sure about this a proposal, it might
be possible to make fly a modified version of the proposal which extended
only those functions which did not deal with positional information.
Pitman wrote SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED based on this idea
and supports at least that much extension, and is sympathetic to (but not
yet fully committed to the idea of the full proposal).
Note that in the SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED proposal,
the function REDUCE is in a grey area. Many of its uses are not
position-dependent, but some are. The same argument might be made about
FIND. If people felt strongly, these too could be extended either by
fudging the conservative rule or by explicit special case(s).
[It's also possible that a still-more-general proposal might be
interesting. For example, one that introduced and inverse to
ARRAY-ROW-MAJOR-INDEX called ARROW-ROW-MAJOR-SUBSCRIPTS, and have
functions like POSITION that returned position information or things
that take :START and :END arguments use subscript (rather than offset)
information. eg,
(SETQ A (MAKE-ARRAY '(2 2) :INITIAL-ELEMENT 0))
(SETF (AREF A 1 0) '1)
(POSITION 1 A) => (1 0) ;Rather than 2 as suggested above
This might ease some people's minds if they're just worried that
returning a 1-d index will feel funny for an any-d array. On the
other hand, the linear ordering must still be well defined so it'll
be clear what the search order is, what range is being selected when
:START and/or :END is used, etc. so you can't hide the issue
completely. Still, if anyone's interested in a full-blown proposal
along these lines, they should ask me and I'll write it. --KMP]
∂28-Apr-87 1334 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Apr 87 13:34:01 PDT
Date: Tue, 28 Apr 87 16:35:56 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
cc: KMP@AI.AI.MIT.EDU
Message-ID: <192342.870428.JAR@AI.AI.MIT.EDU>
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37), global variables (p68),
declaration specifiers (p157)
Category: CLARIFICATION/ENHANCEMENT
Edit history: Revision 2 by JAR 04/28/87
Status: Very preliminary.
Description of problem:
CLtL pp. 55-56 implies that if a name (symbol) is not proclaimed or
declared special, then a free reference to that name is a reference to
the special variable of that name, while a LAMBDA-binding of that name
indicates a binding of the lexical variable of that name. This would
mean that the following program is legal and that (TST) => 4:
(defun tst ()
(setq x 3)
(funcall (let ((x 4)) #'(lambda () x))))
However, if you feed this program to many Common Lisp compilers
(including Symbolics's and DEC's), a warning message will be
produced for the SETQ, saying something like "Warning: X not
declared or bound, assuming special."
These warnings, unlike the annotations of undefined functions (which
occur only at the end of a compilation), are presented so
prominently that a user would be hard put to say that a program
which elicited such warning messages was "correct" in that
implementation. Unlike the situation with unused variables, there is
no possible declaration one can write which suppresses the warning
messages.
This disagreement between theory and practice should be mended
somehow.
Proposal (PROCLAIM-LEXICAL:CURRENT-PRACTICE):
Change the language definition (page 55?) to say that it is an error
for there to be a free reference or assignment to a name unless a
SPECIAL proclamation or declaration is in effect for that name.
This would legitimize the behavior of current implementations.
Proposal (PROCLAIM-LEXICAL:BY-THE-BOOK):
Shame implementors into going by the book. Implementations should
simply stop intimidating users who want to write code like this.
"Apparently unbound variable" warnings should be given the same
purely advisory status that "apparently undefined function" warnings
now enjoy. The exact meaning of this is of course implementation-
dependent.
Proposal (PROCLAIM-LEXICAL:GENERAL):
Introduce a new declaration specifier, LEXICAL, which is dual to the
SPECIAL declaration specifier; it may appear in proclamations and
declarations.
A name may be proclaimed either lexical or special, but not both.
A free reference or assignment to a name is an error if there is
neither a SPECIAL nor a LEXICAL proclamation or declaration in
effect for the name. A LAMBDA-binding in the absence of a
declaration or proclamation binds the lexical variable.
The global lexical environment and the global dynamic environment
are identical. I.e. an assignment to the global binding of a
lexical variable will be reflected in the observed global value of
the dynamic variable of the same name, and vice versa.
Example:
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
Proposal (PROCLAIM-LEXICAL:RESTRICTED):
Same as PROCLAIM-LEXICAL:GENERAL, but with the following restriction:
If a name is proclaimed lexical, then it is an error for there to be
a special declaration of the same name. For example, the special
declaration of X in the example is an error.
Cost of adopting change:
CURRENT-PRACTICE: Ostensibly none, although implementations which
don't signal this as an error should be explicitly encouraged
to do so. It ought to be signalled in interpreted code as well.
BY-THE-BOOK: This would be an easy fix to the error reporting and
bookkeepping components of existing compilers. Of course it is not
a change to the language, so there is no impact on portable code.
GENERAL: This would be straightforward to implement, and is perhaps even
already present, in implementations that use deep binding for
special variables. In shallow bound implementations there's a
problem because two "global" value cells are needed: one for the
current dynamic binding, and one for the global lexical binding;
and when no dynamic binding is in effect, they must somehow be
"coalesced" so that SETQ's are reflected in both.
RESTRICTED: This is specifically designed to address the
implementation problems of GENERAL. Having a dynamic binding and
having a global lexical binding are mutually exclusive.
Benefits:
CURRENT-PRACTICE is incompatible with Scheme, which explicitly
allows a program to have both a global binding and LAMBDA bindings
of the same variable. Therefore, adopting any of the other three
proposals would be a major step towards reducing the
incompatibilities between the two languages, since both code
conversion and embedded scheme implementations would be made easier
and more graceful.
GENERAL and RESTRICTED have the additional advantage that, in an
implementation that uses deep binding for dynamic variables, a
lexical proclamation can be used to achieve significant performance
gains on references and assignments to global variables. A LEXICAL
proclamation would also allow some desirable redundancy, both
for documentation and for error checking.
Cost of converting existing code:
CURRENT-PRACTICE: Some programs may rely on the CLtL semantics;
these would have to be changed if what they're doing now becomes
officially erroneous. People might find consistent enforcement
of this rule rather surprising and frustrating.
GENERAL and RESTRICTED are both upwards compatible. Of course,
code-walking utilities would have to be taught about the new
feature, since it affects the basic semantics of the language.
Aesthetics:
The special/lexical business is generally one of CL's most insidious
and disgusting aspects, and really needs a much more thorough
overhaul than is proposed above (e.g. there ought to be a separate
DYNAMIC-LET or SPECIAL-LET which does dynamic binding). But this is
probably practically and politically infeasible. Given that, I
don't think any of these proposals has clear advantages or
disadvantages from the point of view of simplicity or elegance of
description, except that GENERAL is somewhat easier to describe
than RESTRICTED.
Discussion:
The four proposals indicate the range of possibilities. After some
discussion, we ought to be able to prune this down, of course.
JAR thinks that CURRENT-PRACTICE is unacceptable, BY-THE-BOOK is
unsatisfying but somewhat better, and GENERAL has unsolved implementation
problems, even though it seems the most powerful, symmetric, and elegant.
Thus RESTRICTED seems preferable.
This proposal ignores the question of what to do about an analogue
of DEFVAR or DEFPARAMETER for global lexicals. Interlisp and PSL both
have something along these lines (DEFGLOBAL), don't they?
Given the presence of lexical proclamations in the language, it's
still not clear whether a free, undeclared, unproclaimed reference
should be an error, and if it's not an error, whether it should refer
to the lexical binding or the special binding. I suggest that it not
be an error, and I don't really care what its meaning should be (since
in the situation I care about I'm not going to be dynamically binding
the variable anyhow, so it doesn't matter). The RESTRICTED semantics
would imply that such a reference would have to be to the special
variable.
[By the way, I don't like this use of the term "variable," but I'm
trying to be consistent with CLtL p. 55. Note that according to this
it doesn't make any sense to talk about "declaring a variable to be
special" since any variable is already either special or lexical; it
is names which can be so declared. The book is definitely NOT
consistent about this, and ought to be fixed.]
∂28-Apr-87 1916 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Apr 87 19:16:42 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126601; Tue 28-Apr-87 18:52:26 EDT
Date: Tue, 28 Apr 87 18:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, JAR@AI.AI.MIT.EDU
Message-ID: <870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I support PROCLAIM-LEXICAL:GENERAL if the implementation issues can
be worked out, which I think they can.
I spoke with Jonathan briefly about these problems and I think he
agrees with me that they're not really a problem if you just keep
the global lexical value cells someplace other than the SYMBOL-VALUE
of the symbol.
For example, you might write:
(DEFVAR SYSTEM:*THE-GLOBAL-LEXICAL-VALUE-CELLS* (MAKE-HASH-TABLE))
(DEFUN SYSTEM:GLOBAL-LEXICAL-VALUE-CELL (SYMBOL)
(OR (GETHASH SYMBOL SYSTEM:*THE-GLOBAL-LEXICAL-VALUES-CELLS*)
(SETF (GETHASH SYMBOL SYSTEM:*THE-GLOBAL-LEXICAL-VALUES-CELLS*)
(CONS SYMBOL ;For debugging
SYSTEM:*UNBOUND-MARKER*))))
(DEFMACRO SYSTEM:GLOBAL-LEXICAL-VALUE (SYMBOL)
`(CDR (EVALUATE-AT-LOAD-TIME (SYSTEM:GLOBAL-LEXICAL-VALUE-CELL ',SYMBOL))))
Of course (as stated above), this changes his proposal slightly to
make the global lexical and dynamic environments disjoint. That is,
programs like
(DEFUN MAYBE-EVEN-BUT-SURELY-ODD ()
(+ (LOCALLY (DECLARE (LEXICAL X) (INTEGER X)) X)
(LOCALLY (DECLARE (SPECIAL X) (INTEGER X)) X)))
could return odd numbers (since lexical X and special X might denote
different quantities).
The contract of the compiler would be to turn global lexical
references to a symbol into (SYSTEM:GLOBAL-LEXICAL-VALUE 'symbol).
The call to SYSTEM:GLOBAL-LEXICAL-VALUE-CELL (ie, the GETHASH) need
happen only once (at load time) so its speed is not important.
If the above code wanted to be portable, of course, you'd have to have
an S-expression equivalent to #, called EVALUATE-AT-LOAD-TIME. Most
implementations have such a thing, I think, they just don't let it out
for users to play with. In fact, I think CL should have such a thing
since this isn't the first case where people have wanted it.
In any case, portability isn't relevant to this message since all
that's needed is to demonstrate that it would be feasible to implement
this in all systems, which I think the above code demonstrates.
∂28-Apr-87 2204 masinter.PA@Xerox.COM Re: Issue: PROCLAIM-LEXICAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Apr 87 22:04:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 APR 87 22:04:03 PDT
From: masinter.PA@Xerox.COM
Date: 28 Apr 87 22:02:51 PDT
Subject: Re: Issue: PROCLAIM-LEXICAL
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Tue, 28 Apr
87 18:52 EDT, <870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU, JAR@AI.AI.MIT.EDU
Message-ID: <870428-220403-2039@Xerox>
Jonathan left out the alternative that I thought most natural, namely
that otherwise undeclared
variables were not an error, but would default lexical. E.g.,
(setq x 3)
(defun frob () (incf x))
would not be an error, but would always refer to the lexically global x.
This would bring variable scoping in line with function scoping when
there were no declarations. (A state of grace.)
I presume that Kent didn't really mean to propose that the global
lexical environment be different from the global dynamic environment,
but that was just an awkward artifact of his sample implementation.
Right Kent?
The only idiom which might have portability problems are dynamic calls
to EVAL that get the dynamic binding, e.g., instead of using
SYMBOL-VALUE, e.g., user has a data base of permutations of variables &
values, and also of expressions, binds the variables with PROGV and then
evaluates the expressions.
While current practice is that compilers will warn about undeclared free
references, I know of no interpreter that does, do you?
∂29-Apr-87 0641 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 06:35:52 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126932; Wed 29-Apr-87 09:35:59 EDT
Date: Wed, 29 Apr 87 09:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PROCLAIM-LEXICAL
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
JAR@AI.AI.MIT.EDU
In-Reply-To: <870428-220403-2039@Xerox>
Message-ID: <870429093550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I'm sympathetic to the idea that undeclared free variables should
default lexical. Certainly if we had lexical globals I'd expect that
some compilers would start defaulting free variables lexical while
others would continue to default them special, so perhaps we should
just go ahead and make it well-defined.
Anyway, the separation of global lexical environment from global special
environment seems to me important. After all, you can already do:
(DEFUN F (X) (+ X (LOCALLY (DECLARE (SPECIAL X)) X)))
and see two different variables X without any intervening rebinding.
I was just assuring that this effect was properly carried through.
Also, this assures that people cannot muck with the lexical binding
of any variable. Special variables are kind of 3lispy in nature because
we're told how they're represented and we have primitives for manipulating
them either as variables or as data. I think this makes program proofs
more difficult. The feature of lexical variables is that all of their
uses are statically detectable; this would not be so for global lexicals
if their homes were something that users were permitted to read in a
non-statically-detectable way (eg, using SYMBOL-VALUE) or set (using SETF
of same). By making the lexical bindings totally isolated, you ensure
the right of the compiler to do much better compilation of global lexicals
in some cases than it might be able to do for global specials, and at the
same time you don't make any unpleasant changes to the mechanisms already
in place and in use for specials.
And finally, if you separate the two spaces, then you can go back and
forth between declaring variables special or not without it having strange
effect on things already compiled. eg, if you needed:
(DEFGLOBAL Y 3)
(DEFUN F (X) (+ X Y))
...
(PROCLAIM '(SPECIAL Y))
(DEFUN FOO (Y) (BAR))
(DEFUN BAR () ... (SETQ Y ...) ...)
(PROCLAIM '(LEXICAL Y))
without worrying that the global lexical Y=3 binding was in danger
of getting modified (which it seems intuitive to me that it should
not have been).
MACSYMA, for example, needs an UNSPECIAL declaration because on a
per-file basis it goes back and forth between using the same name either
special or lexical. Alternating back and forth between default LEXICAL
and default SPECIAL would serve it as well if we made that legal.
If such alternation meant that programs previously compiled using the
other semantics were now in error or might behave differently than I
intended at time-of-definition, then you've defeated the purpose of my
doing the alternation. I think the separation of namespaces ensures
intuitive behavior.
∂29-Apr-87 0938 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 09:38:26 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127175; Wed 29-Apr-87 12:38:42 EDT
Date: Wed, 29 Apr 87 12:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870429123832.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: FORMAT-OP-C
References: WRITE-CHAR (p384), ~C (p389)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (merge Moon's suggestion)
Status: For Internal Discussion
Problem Description:
The manual is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should
be culturally compatible with the host environment." This description
is not very useful in practice.
Presumably the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose
that wasn't planned on:
(FORMAT NIL "~C" #\Space) might "Space" rather than " ".
[Anyone who would argue that the word `abbreviated' in the definition
was supposed to prevent this should just be happy that some implementors
didn't choose to interpret that word to mean that "Sp" should come back.]
Some implementations have (FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
It seems as if the implementations which return "Space" treat ~C and
~:C equivalently or very similarly, which seems like a waste of a FORMAT op.
Since the behavior of ~A is also vague on characters (a separate
proposal will address this), the only way to safely output a literal
character is to WRITE-CHAR; FORMAT does not suffice (unless you use
~Q of #'WRITE-CHAR -- which is generally neither pretty nor convenient).
Proposal (FORMAT-OP-C:WRITE-CHAR):
Change the description of ~C on p389 to say:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment.
Add the following to the description of WRITE-CHAR on p384:
Note: The glyphs used to present characters which are not in
the standard character set may vary from implementation to
implementation or output device to output device. WRITE-CHAR
will always output a single character to the indicated stream.
On some streams, super-quoting, character substitution, or
substitution of a string for a single character may be
necessary; it is appropriate for the stream to decide to do
this, but WRITE-CHAR itself will never do this.
Rationale:
This was probably the intent of the authors.
It makes things clear enough that programmers can know what to
expect in the normal case (standard characters with zero bits)
while leaving some flexibility to implementors about what to do in
the case of bits (which are not particularly well-defined across
different implementations anyway).
Current Practice:
Implementations are divided. Some implementations have
(FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Adoption Cost:
Those implementations which did not already implement ~C as WRITE-CHAR
would suffer an incompatible change.
Benefits:
User code that uses ~C would have a chance of being portable.
As things stand, users who use ~C can't reliably port their code.
~C and ~:C would perform usefully distinct operations.
Conversion Cost:
Standard ``Query Replace'' technology for finding occurrences of
"~C" and changing them to "~:C" semi-automatically should suffice.
Aesthetics:
Making ~C do something well-defined will probably be perceived as
a simplification.
Discussion:
Pitman thinks it's important to get this cleared up as soon as possible.
Moon's comment on Version 1 (which tried to make WRITE-CHAR and ~C
identical in all cases) was:
I believe the error in CLtL is that it was not stated explicitly
that the "implementation-dependent abbreviated format" applies only
to characters with non-zero char-bits. Thus instead of removing the
mumbling about cultural compatibility, I suggest simply adding a
sentence saying that ~C is the same as write-char for characters
with zero char-bits. I don't think we want to require ~C and
write-char to do the same thing for characters with bits.
Steele and Fahlman seemed to like the idea of the proposal if amended
as Moon suggested. Pitman did the merge, creating Version 2. If he didn't
blow it somehow, they should now be happy.
∂29-Apr-87 0943 KMP@STONY-BROOK.SCRC.Symbolics.COM status of DEFVAR-INIT-TIME
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 09:43:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127180; Wed 29-Apr-87 12:43:47 EDT
Date: Wed, 29 Apr 87 12:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: status of DEFVAR-INIT-TIME
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <870427-130708-1239@Xerox>
Message-ID: <870429124341.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 27 Apr 87 13:15 PDT
From: Masinter.pa@Xerox.COM
This is my status file. Please mail any corrections you have.
...
I think we are near completion on these, but they need writing work
*SOON*:
DEFVAR-INIT-TIME, ...
I saw no reply at all to DEFVAR-INIT-TIME (other than your mail saying
to please hold off on new proposals until the ones we have get cleaned up).
In the absence of any comments on what might be wrong with this proposal
(which I personally think is pretty non-controversial), I'm not able to
produce an update. If anyone has objections (or just wants to second it
as-is), they should voice them.
∂29-Apr-87 1024 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 10:24:34 PDT
Date: Wed, 29 Apr 87 13:26:40 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: masinter.PA@XEROX.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of 28 Apr 87 22:02:51 PDT from masinter.PA at Xerox.COM
Message-ID: <192793.870429.JAR@AI.AI.MIT.EDU>
Date: 28 Apr 87 22:02:51 PDT
From: masinter.PA at Xerox.COM
While current practice is that compilers will warn about undeclared free
references, I know of no interpreter that does, do you?
The VAX LISP interpreter will generate such warnings if an internal,
unreleased switch is set non-nil. Its default value is nil. For a week
or two when the feature first appeared (only inside DEC, of course) the
switch was defaultly true. Some people liked the immediate feedback,
but overall the warnings were judged too radical and disconcerting, so
the default was changed.
∂29-Apr-87 1025 KMP@STONY-BROOK.SCRC.Symbolics.COM Procedure for Steele's proposed clarifications
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 10:25:44 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127203; Wed 29-Apr-87 13:08:07 EDT
Date: Wed, 29 Apr 87 13:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Procedure for Steele's proposed clarifications
To: Masinter.PA@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
References: <870427-130708-1239@Xerox>
Message-ID: <870429130801.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
If something is in Steele's clarifications (X3J13/86-003), do we
still need to write it up in full blown form for vote?
In particular, does the fact that my AREF-1D proposal overlaps
with the proposal for ROW-MAJOR-AREF mean that I should modify
my proposal to use the new name (which I'm certainly content to
do) or that I should retract my proposal since the same proposal
is already on the floor.
I certainly think that full-blown forms of all the things in
the clarifications would be nice because it would save a lot of
time at meetings answering obvious questions, but some of the
things in that document are pretty simple and straightforward
in their one-liner form and I just want to clarify before doing
a lot of work that expanding them is what is intended.
∂29-Apr-87 1131 KMP@STONY-BROOK.SCRC.Symbolics.COM Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 11:30:54 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127310; Wed 29-Apr-87 14:18:24 EDT
Date: Wed, 29 Apr 87 14:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU
In-Reply-To: <870427-114307-1095@Xerox>
Message-ID: <870429141817.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 27 Apr 87 11:51 PDT
From: Masinter.pa@Xerox.COM
Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
How does this (new) proposal relate to the (old) proposal by Touretsky?
[For Touretzky's context, the "new" proposal being referred to was one to
introduce a function AREF-1D (later renamed to ROW-MAJOR-AREF to correspond
to a name chosen earlier by Steele in a suggested clarifications document
he distributed).]
I'm uncomfortable leaving SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS unfinished
while going ahead with a separate proposal which seems to relate to
similar concerns.
Comments?
At first I wondered if the omission of a proposal to generalize AREF so
that if you gave it a single index it (implicitly asserting it to be a
vector, and hence a sequence), then it should just do a 1-d AREF (as ELT
would do). In fact, however, I think this would decrease error checking
in an undesirable way and my guess is that Touretzky was being very
deliberate in not including a proposal to do this.
Moreover, although some compilers might treat
(ELT (THE ARRAY X) 3)
as efficiently as
(ROW-MAJOR-AREF X 3)
I don't think anyone would be willing to require such efficient treatment.
In compilers which didn't optimize this (and in most interpreters, too)
you'd still have to do the LISTP check before getting around to the
implicit ROW-MAJOR-AREF. Although it isn't suggested that ROW-MAJOR-AREF
is needed only for efficiency, it is true that most applications where it's
likely to be used need maximal efficiency, so I think making it a separate
primitive is appropriate.
All this being said, I think it's safe to make these two proposals proceed
in parallel without worrying that they conflict in some way. If you're not
convinced, please let me know.
∂29-Apr-87 1234 Pavel.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 12:34:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 11:53:00 PDT
Date: 29 Apr 87 11:52 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: FORMAT-OP-C (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:38 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870429-115300-2626@Xerox>
The mention of the non-standard format directive ~Q should be removed
from the proposal. Other than that, I favor it.
Pavel
∂29-Apr-87 1246 KMP@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 12:46:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127412; Wed 29-Apr-87 15:46:19 EDT
Date: Wed, 29 Apr 87 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PRINC-CHARACTER (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870429154611.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I removed the FORMAT-OP-C proposal from this since no one seemed to be
championing it. As far as I know, this was the only simplification anyone
had asked for. -kmp
========================================================================
Issue: PRINC-CHARACTER
References: PRINC (p383)
Category: CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
29-Apr-87, Version 2 by Pitman (removed FORMAT-OP-C)
Status: For Internal Discussion
Problem Description:
The manual is not adequately specific about the function of PRINC
when given a character as an argument.
For example, does (PRINC #\Space) print ``Space'' or `` ''?
The advice that "the general rule is that output from PRINC is
intended to look good to people" is the root of a lot of the problem.
The truth is that what looks good varies with context. viz,
* For (FORMAT NIL "Foo~ABar" #\Space)
Pretty result: "Foo Bar"
Ugly result: "FooSpaceBar"
In other words, " " looks better here.
* For (FORMAT T "Type ~C to continue" #\Space)
Pretty result: "Type Space to continue"
Ugly result: "Type to continue"
In other words, "Space" looks better here.
Proposal (PRINC-CHARACTER:WRITE-CHAR):
(PRINC char stream) should be defined to be equivalent to
(WRITE-CHAR char stream).
Rationale:
The behavior of (PRINC char) should be well-defined even if a
completely arbitrary decision had to be made.
In fact, though, we can get some advice by appealing to history.
The only data type which corresponds to characters in most old
lisps was symbols. For example, in Maclisp,
(PRINC char-symbol) == (TYO (GETCHARN char-symbol 1))
In Common Lisp, it would make sense in the absence of arguments
to the contrary to preserve an analagous relation, namely:
(PRINC char) == (WRITE-CHAR char)
Current Practice:
Vaxlisp, Symbolics, Spice Lisp, and Lucid all print " " and not
"Space" for (PRINC #\Space).
Symbolics and Spice are known to use the WRITE-CHAR strategy.
Vaxlisp and Lucid might be using it, too, or they might be
using ~C in FORMAT; no one familiar with their internals has
commented.
In any case, some other implementations are believed to differ
(ie, to output "Space" when you PRINC a #\Space), but a specific
reference is not currently available. In any case, the wording
in CLtL is not clear enough to preclude such a differing
implementation from `legitimately' emerging.
Adoption Cost:
Any implementations which did not already implement this proposal
decided upon would suffer an incompatible change.
Benefits:
User code that uses PRINC (and presumably ~A) on characters would
have a chance of being portable.
Conversion Cost:
It's easy to search for occurrences of PRINC and ~A in code, but
it may not always be apparent when the argument is a character.
Automatic conversion is unlikely to succeed.
Aesthetics:
Making PRINC do something well-defined for as many primitive data
types as possible will probably be perceived as a simplification.
Discussion:
KMP thinks this is moderately important because it is embarrassing
to have commonly used functions like this vary so widely in behavior
between implementations. He doesn't think it is critical because
(if nothing else) it is only one of many problems with the vague
contract of PRINC.
There was an alternate proposal PRINC-CHARACTER:FORMAT-OP-C which
suggested making PRINC work like ~C in FORMAT, but no one seemed
to think that was useful and the proposal was removed for Version 2
to keep from muddying what's likely to be a very straightforward
vote in favor of PRINC-CHARACTER:WRITE-CHAR.
∂29-Apr-87 1337 KMP@STONY-BROOK.SCRC.Symbolics.COM IF-BODY (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 13:37:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127499; Wed 29-Apr-87 16:37:14 EDT
Date: Wed, 29 Apr 87 16:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF-BODY (Version 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870427182129.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
Message-ID: <870429163704.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I hope this draft manages to merge the IF-BODY:NO stuff in
a relatively fair way. -kmp
``... looks reasonably balanced to me, and represents my
own opinions adequately. I see no objection to releasing
it to the world at large ...''
-- Guy L. Steele, Jr.
author of ``Common Lisp: The Language''
==============================================================================
Issue: IF-BODY
References: IF (p115)
Category: ENHANCEMENT
Edit history: 27-Feb-87, Version 1 by Pitman (IF-BODY:YES)
3-Mar-87, Version 2 by Fahlman (added IF-BODY:NO)
17-Apr-87, Version 3 by Masinter (merged v1 and v2)
19-Apr-87, Version 4 by Pitman (misc editing to v3)
27-Apr-87, Version 5 by Pitman (reworked for balance)
Status: Not for release
Problem Description:
CLtL defines the meaning of an IF expression only in the case of two or
three arguments. Some implementations extend the meaning to allow more
arguments.
Typically, using the extended IF syntax will not generate a warning in
environments which support it. Code developed where these features are
available is not typically discovered to be in error until a port to
some other implementation is attempted. At that point, which is
typically inconveniently late in the development cycle, the developer
may notice that code either does not compile (generates syntax errors)
or does not compile correctly (the additional forms are quietly ignored
and the code generated is not what the writer intended).
The problem is rightly due to the user, but users typically expect that
they should be warned about such problems. Unfortunately, however, both
the Lisp which allows the extended syntax and that which fails to signal
an error about the invalid syntax are within their rights as currently
stated.
This phenomenon is a barrier to Common Lisp's portability goals.
Test Case:
(IF NIL 'THEN 'ELSE 'MORE)
According to CLtL, this is an error.
In some implementations, this returns ELSE.
In some implementations, this returns MORE.
In some implementations, this signals an error at syntax analysis time.
Notes about Voting:
Select one of IF-BODY:ILLEGAL, IF-BODY:LEGAL, or IF-BODY:UNCHANGED.
Proposal (IF-BODY:ILLEGAL):
Restrict IF, making it expressly illegal to supply more than three
argument forms. Require that implementations signal an error at
syntax analysis time.
Rationale:
As long as some implementations provide this extension while
others do not, the portability goals of Common Lisp will suffer.
It is not adequate to encourage implementors to warn about
non-standard uses since the only implementations which will
implement the extension are ones who think it is a good idea to
use the feature, and people are not inclined to warn about things
they think are a good idea to use.
Although some implementations offer extended definitions and
this would be an incompatible change, the cost of that change
would be offset by the improvement in code portability.
Adoption Cost:
The direct act of making this restriction is trivial, but there
are nth order effects which may be non-trivial...
In Symbolics implementations the SCL package contains Symbolics'
extensions to LISP. Currently, for any symbol LISP:xxx, the
expression (EQ 'LISP:xxx 'SCL:xxx) => T. This change would force
as a second order effect a decision about whether to make
(EQ 'LISP:IF 'SCL:IF) => NIL or to rewrite all code (user and
system) using the extended IF.
Since there are currently no cases where LISP symbols are not
shared by SCL, a decision to break the sharing would force us
to do a complicated re-evaluate our position on the nature of
compatibility between Common Lisp and the extensions we provide.
The cost of this option is therefore potentially large.
Conversion Cost:
Uses of IF in correct Common Lisp code are technically unaffected
by this change, although it should be clear from the discussion
of Adoption Cost that viewing things this way may be just a word
game. In practice, there might be non-trivial effects on
code that is not technically `Common Lisp' but which is thought to
be `Common Lisp compatible.' The importance of this must be weighed
in context, but should not be discounted altogether.
Benefits:
Code portability between certain dialects would be improved.
Aesthetics:
The (IF test then else) syntax is neatly symmetric and this
symmetry should be preserved.
Some people find the asymmetry of the (IF test then {else}*)
syntax to be visually confusing.
IF is supposed to be the simplest conditional form, from which
all the others are built.
Proposal (IF-BODY:LEGAL):
Extend IF, making it expressly legal to supply an implicit-PROGN of
`else' forms using the syntax (IF test then {else}*).
Rationale:
As long as some implementations provide this extension while
others do not, the portability goals of Common Lisp will suffer.
It is not adequate to encourage implementors to warn about
non-standard uses since the only implementations which will
implement the extension are ones who think it is a good idea to
use the feature, and people are not inclined to warn about things
they think are a good idea to use.
Although some implementations offer extended definitions and
this would be an incompatible change, the cost of that change
would be offset by the improvement in code portability.
Adoption Cost:
In most implementations, making this syntax legal is a matter of
a fairly localized change to a finite number of utilities which
reason about programs (compiler, interpreter, code walkers). No
changes to code which does not reason about programs would be
necessary.
In some implementations which have incompatible extension
strategies, such as keyword-driven facilities, the cost is higher
because this is an incompatible change. The cost of adoption in
such cases is hard to estimate; implementors who feel they have
severe concerns about this should raise those concerns and we'll
modify this proposal to reflect them.
Benefits:
Code portability between certain dialects would be improved.
Aesthetics:
The resolution of this controversial programming style issue
is left to the user rather than being forced by the language
designer. Those who prefer the symmetry of the (IF test then else)
syntax are free to use it exclusively without infringing on the
desires of others to use the extended syntax.
Some people find the alternatives to (IF test then {else}*) to
be too visually cumbersome.
Although IF was supposed to be a simple conditional form, usage
patterns suggest that this is not uppermost in many users' minds.
Experience in user communities where extended IF is available
show that few users object to its presence; most are happy for
the syntactic flexibility it provides.
Proposal (IF-BODY:UNCHANGED):
Leave IF as currently specified in CLtL.
Implicit in this proposal is that it would be valid for any
implementation to extend IF as long as such an extension was done
in a way that was `upward compatible' with Common Lisp.
Rationale:
The other two proposals are inadequately motivated.
Since some implementations already support extensions, it would
be disruptive to those implementations to require that the
extensions be removed. Not altering the current definition is
maximally conservative with regard to existing code.
Adoption Cost:
Making this syntax legal is trivial since everyone is
presumably already compatible with the existing standard.
Implicit in the acceptance of this proposal, however is the
incremental cost of late debugging of programs which are in error
but for which no diagnostic has been generated because we have
not required such a diagnostic.
Benefits:
The current state of the world would be unaffected.
Aesthetics:
The (IF test then else) syntax is neatly symmetric and this
symmetry should be preserved.
Some people find the asymmetry of the (IF test then {else}*)
syntax to be visually confusing.
IF is supposed to be the simplest conditional form, from which
all the others are built.
Current Practice:
Some implementations already provide this feature.
A few implementations provide alternate keyword-driven extensions
that are incompatible with the IF-BODY:LEGAL extension.
Some implementations signal an error if other than two or three
arguments are passed.
Some implementations quietly ignore additional arguments to IF (making
it hard to detect errors in code that was developed on systems with
the extended syntax).
Discussion:
MACSYMA ran into this problem.
KMP supports IF-BODY:LEGAL.
Steele and Fahlman support IF-BODY:UNCHANGED.
Moon has no strong opinion.
Fahlman expressed strong concern about the potential precedent which
could be set by using compatibility concerns as a lever to introduce
all kinds of unwanted idiosyncratic extensions present in only one
implementation and no other.
Moon suggested that the mere fact that some people like an extension
is not sufficient reason to put it into the language, but is
sufficient reason to -discuss- putting it into the language.
Steele notes that one of the reasons for including IF in the language
is to have a simple primitive that can easily be recognized, by people
and by program-walkers alike, as being the simplest conditional and
not having implicit PROGNs as do WHEN, UNLESS, and COND.
KMP thinks the language is already so cluttered that worrying about
such a tiny change to IF is unwarranted. He thinks that if the only
concern was primitive simplicity, we should just redefine the layer
at which simplicity is achieved by letting LISP:IF be a macro that
expands into PRIMITIVE:IF which has simpler semantics but which no
one has to be stuck programming with (if they don't want to). You
could argue that users should make their own JDOE:IF macro that has
this extension, but since this is likely to be a common extension, it's
our place to consider it for adoption as part of the standard.
∂29-Apr-87 1404 gls@Think.COM AREF-1D
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 14:04:18 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 29 Apr 87 15:19:45 EDT
Date: Wed, 29 Apr 87 15:16 EDT
From: Guy Steele <gls@Think.COM>
Subject: AREF-1D
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870424015232.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870429151657.4.GLS@BOETHIUS.THINK.COM>
Date: Fri, 24 Apr 87 01:52 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
In any case, although I did have reasons for the choice of name, I'm
not passionate about them. Since there's already a precedent for the
other name, I'm happy to go with that. ROW-MAJOR-AREF is fine.
I am not passionate either. AREF-1D has the advantage of brevity.
By the way, I think an inverse to ARRAY-ROW-MAJOR-INDEX might nicely
round out the set of operations which took an offset and either a list
of dimensions or an array and returned the standard reference pattern
might nicely round out the set of operations in this family...
This is a good idea.
--Guy
∂29-Apr-87 1406 gls@think.com AREF-1D
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 14:05:52 PDT
Received: from THINK.COM by navajo.stanford.edu with TCP; Wed, 29 Apr 87 14:04:23 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 29 Apr 87 15:20:50 EDT
Date: Wed, 29 Apr 87 15:17 EDT
From: Guy Steele <gls@think.com>
Subject: AREF-1D
To: edsel!bhopal!jonl@navajo.stanford.edu,
navajo!gls%Think.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%sail@navajo.stanford.edu, gls@think.com
In-Reply-To: <8704240436.AA06857@bhopal.edsel.com>
Message-Id: <870429151757.5.GLS@BOETHIUS.THINK.COM>
Date: Thu, 23 Apr 87 21:36:52 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Since CLtL already specified ARRAY-ROW-MAJOR-INDEX, this addition seemed
very natural and "called for". So Lucid Common Lisp has had it available
since shortly thereafter.
Foo. It just goes to show that I can't remember what's in the book either.
∂29-Apr-87 1501 Masinter.pa@Xerox.COM Re: status of DEFVAR-INIT-TIME
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 15:01:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 14:17:27 PDT
Date: 29 Apr 87 14:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: status of DEFVAR-INIT-TIME
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:43 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870429-141727-2814@Xerox>
I put DEFVAR-INIT-TIME in the "we can release this soon" because I
presumed that it was so trivial there would be no objection. Usually its
a mistake to make any such presumptions, but one can always hope....
∂29-Apr-87 1722 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 17:22:30 PDT
Received: by navajo.stanford.edu; Wed, 29 Apr 87 17:22:02 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA01519; Wed, 29 Apr 87 16:33:45 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA13102; Wed, 29 Apr 87 16:30:59 PDT
Date: Wed, 29 Apr 87 16:30:59 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704292330.AA13102@bhopal.edsel.com>
To: navajo!KMP%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 29 Apr 87 09:35 EDT
Subject: Issue: PROCLAIM-LEXICAL
In a deep-bound Lisp, it is critically important to be able to distinguish
"global" access/update from "special", or "fluid" access/update. A note
I sent to the CL mailing list about a year ago stressed this point; it
explained the semantic differences and showed some performance consequences.
There were not many replies about it since almost all Common Lisps are
currently shallow-bound [the upcoming Xerox effort will be an exception,
and some parallel research versions of Common Lisp are also an exception]
Since none of these proposals for clarifying the semantics of undeclared
variables propose to do away with "special" variables, then the question
of global/fluid distinction for "specials" is still relevant. So I'm a
bit concerned about the proposal to add yet a third environment, the
"global lexical", which doesn't address this concern.
Consider, for a moment, the example:
(let ((x 1))
(declare (special x))
(load "some-file"))
where the contents of "some-file" are
(setq x (+ x 3))
The historic interpretation is that this SETQ applies to the special
binding of x. To get the effect of setting the global "fluid" binding,
one would have to say something like
(proclaim '(global x))
(setq x (+ x 3))
or like
(locally (declare (global x)) (setq x (+ x 3)))
or use functions like Interlisp's "topval" functions:
(settopval 'x (+ (gettopval 'x) 3))
In this example, it would/should be illegal to lambda-bind x if it were
declared "global"; thus it is quite satisfactory to use the shallow-binding
value cell as both the "global" cell and the "special" cell; For many
reasons, it is very convenient to have the "top-level" fluid environment
be the same as the global environment.
That's why I'm a bit taken aback by your proposal that the "global lexical"
could not share with the global dynamic (fluid) environment. Whereas there
is the demonstrated need for a declaration which distinguishes special
variables from global variables, where is the need for a distinct, yet
parallel, global lexical environment?
-- JonL --
∂29-Apr-87 1744 Moon@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 17:44:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127770; Wed 29-Apr-87 20:26:29 EDT
Date: Wed, 29 Apr 87 20:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PRINC-CHARACTER (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870429154611.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870429202621.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor PRINC-CHARACTER:WRITE-CHAR.
∂29-Apr-87 1744 Moon@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 17:44:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127778; Wed 29-Apr-87 20:29:19 EDT
Date: Wed, 29 Apr 87 20:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870429123832.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870429202910.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor FORMAT-OP-C:WRITE-CHAR.
∂29-Apr-87 1844 Masinter.pa@Xerox.COM Re: FORMAT-OP-C (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 18:44:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 18:45:08 PDT
Date: 29 Apr 87 18:46 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: FORMAT-OP-C (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:38 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870429-184508-3208@Xerox>
Kent, I'll point out again that the proposal should not say "Change the
wording on p. 3241 to say...". The proposal should describe what ANSI
Standard Lisp should do, not what Guy Steele's second edition should
say. The words you use can be pretty much the same, but a number of
folks expressed some sensitivity that the cleanup committee not dictate
wording.
E.g., rather than
" Change the description of ~C on p389 to say:
~C prints the character using WRITE-CHAR if it has zero bits.
Characters with bits are not necessarily printed as WRITE-CHAR
would do, but are displayed in an implementation-dependent
abbreviated format that is culturally compatible with the host
environment."
Proposal (FORMAT-OP-C:WRITE-CHAR):
The ~C option of format, when given a character with zero bits, will
perform the same action as WRITE-CHAR. (The behavior of FORMAT with the
~C directive given a character with non-zero bits attributes remains
unspecified.)
∂29-Apr-87 1926 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87 19:26:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127905; Wed 29-Apr-87 22:26:18 EDT
Date: Wed, 29 Apr 87 22:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <192342.870428.JAR@AI.AI.MIT.EDU>
Message-ID: <870429222608.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I remember some of this being discussed before, and there being some
reason for not doing it that I couldn't remember, so I went back
through some old Common Lisp documents I have held onto. Here's
what I found:
21 Dec 1981 Issue #70 - we discussed the issue of what undeclared
free variable references mean, but couldn't decide. The alternatives
offered weren't very deep:
(a) interpreter and compiler warn
(b) interpreter never warns, compiler is permitted to warn
(c) "status quo" [it said] the interpreter never warns, but the compiler
never warns for top level forms, but is permitted to warn inside functions
21 Dec 1981 Issue #72 - we tentatively introduced a LOCAL declaration,
meaning not SPECIAL. This was by analogy with the UNSPECIAL declaration
of Maclisp and Zetalisp, but we decided to change the name. I don't
think we had completely understood the DECLARE/PROCLAIM distinction
at that time (although we were discussing it) so I'm not sure what
LOCAL meant as a proclamation; I think the idea was just that as a
declaration it could be used to shadow a SPECIAL proclamation.
8/14/82 I found a note of mine saying "there is no way to declare
a variable not special. I guess this got taken out when special was
changed not to be pervasive. This needs to be fixed."
8/21/82 Common Lisp meeting Issue #78: Need some kind of declaration to
locally shadow a globally pervasive special declaration [I think that's
a special proclamation in current terminology]. I have written down that
"the vote was yes, GLS will propose, read JonL's paper". I don't have a
clue which JonL paper this refers to.
In all later documents, there is special but no unspecial nor local.
This confirmed my memory that a lexical declaration had been put in and
then taken out, but I was unable to find any written rationale for the
decisions, which is what I was really looking for. I didn't go so far
as to search the electronic mail archives (but I don't think they go
back all the way to 1981).
∂29-Apr-87 1951 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87 19:51:22 PDT
Date: Wed, 29 Apr 87 22:53:15 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: edsel!bhopal!jonl@NAVAJO.STANFORD.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@MX.LCS.MIT.EDU
In-reply-to: Msg of Wed 29 Apr 87 16:30:59 PDT from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
Message-ID: <193127.870429.JAR@AI.AI.MIT.EDU>
Date: Wed, 29 Apr 87 16:30:59 PDT
From: edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
So I'm a bit concerned about the proposal to add yet a third
environment, the "global lexical", which doesn't address this
concern.
I'm having trouble understanding how you count environments. I count a
total of four:
1. lexical LAMBDA-bindings
2. global lexical
3. dynamic LAMBDA-bindings
4. global dynamic
KMP doesn't suggest ADDING a global lexical environment; the global
lexical environment is already there in the GENERAL and RESTRICTED
proposals. He merely suggests making it not be identical to the global
dynamic environment. This would make a total of 4 environments, not 3.
I tend to think of 2 and 4 as being part of 1 and 3. This is consistent
if you imagine that there's an immense cosmic LAMBDA surrounding all
the programs in the world; this LAMBDA binds all possible names.
I have no opinion at this point on the virtues of KMP's amendment.
In this example, it would/should be illegal to lambda-bind x if it were
declared "global"; thus it is quite satisfactory to use the
shallow-binding value cell as both the "global" cell and the "special"
cell...
This proposal is even more restrictive than RESTRICTED. I see no reason
to impose this restriction, and I see Scheme compatibility as a big
reason that we SHOULD allow lambda-binding variables which have global
bindings. The RESTRICTED proposal seems to give you everything you want
-- it allows you to have a single global value cell in
shallow-dynamic-binding implementations, and it allows the desired
performance advantages in deep-dynamic-binding implementations. Why do
you want to rule out lexically lambda-binding global variables? Does
this have something to do with shallow lexical binding?
If I have told you something you didn't already know, or if you still
don't understand what I'm getting at, how can I make the proposals
clearer?
Jonathan
∂30-Apr-87 0053 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 00:53:24 PDT
Received: by navajo.stanford.edu; Thu, 30 Apr 87 00:52:55 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA03157; Wed, 29 Apr 87 23:47:27 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA13625; Wed, 29 Apr 87 23:44:42 PDT
Date: Wed, 29 Apr 87 23:44:42 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704300644.AA13625@bhopal.edsel.com>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 29 Apr 87 22:26 EDT
Subject: Issue: PROCLAIM-LEXICAL
Re :8/21/82 Common Lisp meeting Issue #78: Need some kind of declaration to
locally shadow a globally pervasive special declaration [I think that's
a special proclamation in current terminology]. I have written down that
"the vote was yes, GLS will propose, read JonL's paper". I don't have a
clue which JonL paper this refers to.
This "Common Lisp meeting" was held at CMU just after the 1982 Lisp
Conference. The "JonL paper" in question could hardly be anything
other than my contribution to that conference. It had a long title
something like "Constant Time Interpretation for Variables, in the
Presence of Mixed SPECIAL/LOCAL Declarations". It described the VAX/NIL
interpreter, and how it processed "special" and "unspecial" declarations
by pushing a block similar to what a lambda-binding would do, and
how the interpretation of a variable reference was resolved by comparing
"declarational level number" with "binding level number". It was full
of cute little acronyms, for which I can blame GLS.
I vaguely remember some flaming about LOCAL declaration being unnecessary
because, unlike in MacLisp, the SPECIAL declaration of Common Lisp wasn't
to be pervasive. As you say, I think the "flamers" totally blew it because
of not understanding the difference between DECLARE and PROCLAIM.
-- JonL --
P.S. The technique described in the above-mentioned paper was strictly
for a shallow-bound, non-parallel implementation. I don't think
I see how to generalize it otherwise.
∂30-Apr-87 1425 Masinter.pa@Xerox.COM Re: status of DEFVAR-INIT-TIME
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 14:25:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 14:26:24 PDT
Date: 30 Apr 87 14:26 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: status of DEFVAR-INIT-TIME
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 12:43 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870430-142624-4291@Xerox>
I support DEFVAR-INIT-TIME as submitted.
If there is no objection, we can release it as is.
∂30-Apr-87 1429 Masinter.pa@Xerox.COM Re: Procedure for Steele's proposed clarifications
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 14:29:41 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 30 APR 87 14:29:41 PDT
Date: 30 Apr 87 14:31 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Procedure for Steele's proposed clarifications
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 13:08 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870430-142941-4301@Xerox>
Many of the issues that are before us occured in Steele's list of
proposed clarifications, and, even though simple at first glance, seemed
to require the full-blown form.
If there is a subset of the clarifications which we can agree on without
discussion, then I'd be happy to proceed with them; if we all agree, we
can just submit them as a set of "obvious clarifications". I'm a little
skeptical that there are many like that. Do you have some candidates in
mind?
∂30-Apr-87 1459 Masinter.pa@Xerox.COM Re: Status of IGNORE-ERRORS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 14:59:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 15:00:12 PDT
Date: 30 Apr 87 14:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Status of IGNORE-ERRORS
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 16:25 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu, Daniels.pa@Xerox.COM
Message-ID: <870430-150012-4352@Xerox>
The only thing hanging up the signalling proposal is that that committee
(and mainly Kent Pitman) needs to bring it up before the next X3J13. It
is an excellent proposal and we should adopt it and get on with it.
There's no point in adopting IGNORE-ERRORS when we could get the whole
thing.
This was originally my paraphrase of Pavel's comments, but I've really
written what I think. At the meeting before X3J13 you were pretty
mysterious about your reasons for thinking the error proposal would take
too long, or longer than this committee would take.
Comments?
∂30-Apr-87 1502 Masinter.pa@Xerox.COM Re: IF-BODY (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 15:01:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 15:00:55 PDT
Date: 30 Apr 87 14:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: IF-BODY (Version 5)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 29 Apr 87 16:37 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <870430-150055-4353@Xerox>
In the interest of getting this out of our hair, I think we could
release it as is. As a point for future proposals, I would like to
discourage "status quo" alternatives in enhancement proposals, since
every proposal has an implicit "status quo" alternative, and some of the
arguments are redundant. I had expected you would just elaborate in the
Discussions section, but ... whatever ...
Sometimes this process seems so mind-numbingly bureaucratic...
∂30-Apr-87 1638 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 16:38:24 PDT
Received: by navajo.stanford.edu; Thu, 30 Apr 87 16:37:55 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA06279; Thu, 30 Apr 87 16:13:47 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA01123; Thu, 30 Apr 87 16:11:01 PDT
Date: Thu, 30 Apr 87 16:11:01 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704302311.AA01123@bhopal.edsel.com>
To: navajo!JAR%AI.AI.MIT.EDU@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu,
navajo!KMP%MX.LCS.MIT.EDU@navajo.stanford.edu
In-Reply-To: Jonathan A Rees's message of Wed, 29 Apr 87 22:53:15 EDT
Subject: Issue: PROCLAIM-LEXICAL
Re: KMP doesn't suggest ADDING a global lexical environment; the global
lexical environment is already there in the GENERAL and RESTRICTED
proposals. He merely suggests making it not be identical to the global
dynamic environment. This would make a total of 4 environments, not 3.
Since this "global lexical" environment isn't to be identical with the
"global fluid" environment, then it's a "new" environment as far as
Common Lisp is concerned; that's why I said he was "adding" something.
With respect to environments for a "free variable" reference, there are3,
not 4, possibilities. A lexically-bound variable isn't free, and hence
not, I thought, of concern to this discussion [which was opened up by your
attempt to clarify the semantics of free variables].
Have I misread anything here? Your proposals were clearly worded enough;
I only wanted to bring up an objection to the idea of having two totally
distinct global environments. I think calling it an "addition" or not
is a really minor point.
Re: . . . I see no reason
to impose this restriction, and I see Scheme compatibility as a big
reason that we SHOULD allow lambda-binding variables which have global
bindings. . . .
I think you misread this completely backwards. It WASN'T that you couldn't
lambda-bind anything that had a binding in the global environment. It WAS
that you couldn't lambda-bind anything that was explicitly declared or
proclaimed GLOBAL rather than SPECIAL (or LOCAL?).
In an implementation where the global fluid environment is the same as
the top-level environment (the standard state for virtually all deep
and shallow bound Lisps -- but not for Lisp 1.5), then a SETting
of any variable without a dynamically intervening lambda-binding would
just make a global/top-level binding. This would happen independently
of whether the variable was proclaimed GLOBAL or SPECIAL. But a variable
delcared GLOBAL would only affect the top-level binding; not any
intermediate SPECIAL lambda-bindings.
Do you see the difference here? or does this point need more explication?
-- JonL --
∂30-Apr-87 1818 Masinter.pa@Xerox.COM Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87 18:18:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 16:46:05 PDT
Date: 30 Apr 87 16:48 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: cl-cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU
Message-ID: <870430-164605-4496@Xerox>
fyi, this is the reaction from our local array expert...
----- Begin Forwarded Messages -----
Date: 30 Apr 87 15:07 PDT
From: Pedersen.pa
Subject: Re: [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>:
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)]
In-reply-to: Masinter.pa's message of 30 Apr 87 14:17 PDT
To: Masinter.pa
cc: pedersen.pa
Don't really like either proposal -- because they seem like hacks
rather than a serious approach to the problem. Also, Common Lisp is
already over-bloated, it just doesn't need creeping featurism -- but
rather a trimming down. After all -- these proposals simply relieve the
user of the very minor chore of making displaced arrays for the rare
instances where that is the natural thing to do -- no real value is
added, but there is a cost in complexity, and possibly performance.
The truth is that if you really want to do multi-dimensioned array
manipulation, you really do want something like APL, or close to it.
Implementing an array calculus -- like APL -- is quite doable (I have
something close to that floating around), and is the right way to go for
heavy array users, but I don't think that functionality needs to be
built into the language.
J.P.
----- End Forwarded Messages -----
∂30-Apr-87 1901 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 19:01:20 PDT
Date: Thu, 30 Apr 87 22:03:41 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: edsel!bhopal!jonl@NAVAJO.STANFORD.EDU
cc: KMP@AI.AI.MIT.EDU, CL-Cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Thu 30 Apr 87 16:11:01 PDT from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
Message-ID: <193809.870430.JAR@AI.AI.MIT.EDU>
Date: Thu, 30 Apr 87 16:11:01 PDT
From: edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
With respect to environments for a "free variable" reference, there are3,
not 4, possibilities. A lexically-bound variable isn't free, and hence
not, I thought, of concern to this discussion [which was opened up by your
attempt to clarify the semantics of free variables].
OK, I see. "Free" means lexically free.
Re: . . . I see no reason
to impose this restriction, and I see Scheme compatibility as a big
reason that we SHOULD allow lambda-binding variables which have global
bindings. . . .
I think you misread this completely backwards. It WASN'T that you
couldn't lambda-bind anything that had a binding in the global
environment. It WAS that you couldn't lambda-bind anything that was
explicitly declared or proclaimed GLOBAL rather than SPECIAL (or
LOCAL?).
Since you are implicitly proposing a third kind of declaration (GLOBAL,
in addition to SPECIAL and my proposed LEXICAL), I take this as an
implicit criticism of the proposal; you must consider it inadequate or
else you wouldn't be suggesting this new and different idea. I'm
wondering what
(PROCLAIM '(GLOBAL ...))
gives you that
(PROCLAIM '(LEXICAL ...))
doesn't. Forgetting our differences in conceptual model and terminology
for the moment, the ONLY difference I see between these (assuming the
RESTRICTED proposal), either semantically and pragmatically, is that a
variable that proclaimed GLOBAL cannot be lexically lambda-bound.
Therefore I don't see what GLOBAL adds to my proposal or why you are
suggesting that it's a good idea. (Certainly in the absence of
(PROCLAIM '(LEXICAL ...)), it is a good idea.)
I.e. I don't see how your "global" variables are different from my
"global lexical" variables.
Getting back to terminology: why do you think LOCAL is a better name
than LEXICAL? LEXICAL seems more general and more descriptive to me, as
long as you buy the idea that there is such a thing as a top-level
(global) environment, which serves as BOTH the top-level lexical
environment and as the top-level dynamic environment (unless KMP has his
way).
Jonathan
∂01-May-87 1536 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 15:36:11 PDT
Received: by navajo.stanford.edu; Fri, 1 May 87 15:35:37 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA09971; Fri, 1 May 87 13:15:07 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA00639; Fri, 1 May 87 13:12:21 PDT
Date: Fri, 1 May 87 13:12:21 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705012012.AA00639@bhopal.edsel.uucp>
To: navajo!JAR%AI.AI.MIT.EDU@navajo.stanford.edu
Cc: navajo!KMP%AI.AI.MIT.EDU@navajo.stanford.edu,
navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: Jonathan A Rees's message of Thu, 30 Apr 87 22:03:41 EDT
Subject: Issue: PROCLAIM-LEXICAL
I believe that the deep-binders would be satisfied with top-level
environment being called "global lexical", providing that the "global
special" (or, "global fluid" if you will) is the same. The main issue
is: What does a special reference mean when there is no dynamically
intervening special binding? Is it ok for it to access the "global
lexical" binding? I wouldn't want to go so far as to make an alternative
proposal, providing you agree that this is no problem with the single
top-level environment. [Larry -- could you volunteer some opinion?
This issue will probably affect Xerox's Lisp the most?].
Re: Getting back to terminology: why do you think LOCAL is a better name
than LEXICAL? LEXICAL seems more general and more descriptive ...
To me, "lexical" means "lexically apparent", or "lexically constrained".
In the example:
(DEFUN FOO (X) (DECLARE (SPECIAL X)) (LIST (BAR X) (BAR X)))
both instances of "X" in the calls to "BAR" are "lexical" with respect
to its binding; but "X" isn't lexically bound, it is dynamically bound.
[Note also; it is not "free".] Consider the (free) occurances of "X" in
some other module, which in fact might access the value of this binding;
they are not "lexically apparent". For this reason -- wanting to talk
about lexical context and not imply anything about the bindings of
variables therein -- I tend to prefer another term for the opposite of
SPECIAL. But I'm not at all enamored with the term LOCAL, or even
UNSPECIAL; LEXICAL would be ok as long as the documentation clearly
stressed this point.
-- JonL --
∂01-May-87 1656 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87 16:56:31 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130001; Fri 1-May-87 19:56:58 EDT
Date: Fri, 1 May 87 19:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU,
Pedersen.pa@Xerox.COM
In-Reply-To: <870430-164605-4496@Xerox>
Message-ID: <870501195646.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 30 Apr 87 16:48 PDT
From: Masinter.pa@Xerox.COM
fyi, this is the reaction from our local array expert...
...
Date: 30 Apr 87 15:07 PDT
From: Pedersen.pa
... they seem like hacks rather than a serious approach to
the problem. ...
My guess is that it looks hackish more from a historical perspective
than it would if you just saw a new edition of the manual that didn't
refer to these as sequence functions. Surely if you were just told from
scratch that arrays were valid arguments to MAP or COUNT, you wouldn't
have thought it even remotely hackish. You'd likely say: "Of course."
I think your view may be skewed by feeling like we'll still have a sequence
functions chapter that will say "Oh, by the way, as a special case, MAP
and count will treat arrays as sequences displaced to their storage."
The argument about displacement is the rationale for the argument (and
for why it won't be efficient) more than advice for how the result might
be presented in the manual.
Pedersen: ... these proposals simply relieve the user of the very
minor chore of making displaced arrays for the rare instances where
that is the natural thing to do -- no real value is added, ...
Actually, I bet some people don't ever used displaced-arrays because
they seem like excess hair and/or because the side-effect consequences
are hard to learn about. RPLACA and RPLACD are hard to learn, but they
are taught about in lots of classes and lots of books so people
eventually catch on. Displaced arrays may be taught in some thorough
courses and one or two advanced books, but I bet are largely overlooked.
Not to mention the fact that they inherently seem to violate an
abstraction and some people might avoid them because of some feel that
programs which use them are not clean. On the other hand, there's
nothing even remotely unclean about using an operator like MAP or COUNT
on an array if that operator is willing to do the work for you. It's
not the machine instructions that count, it's what the program has to
say in order to make the machine instructions get executed that's of
interest.
Pedersen: ... but there is a cost in complexity, ...
I'd find it easier to remember a rule saying that "SUBSTITUTE does
top-level substitution in aggregate quantities" than one that says
"SUBSTITUTE does top-level substitution in vectors" because
"aggregate quantities" is a natural concept that I've been dealing
with for much longer than programming and "vector" is a domain
specialized (and in this case very arbitrary) restriction on that
natural concept. I'd consider it a simplification if SUBSTITUTE worked
on arrays.
Pedersen: ... and possibly performance. ...
I bet the performance hit is not remarkably large...
* I'd think compilers which can optimize these function calls
based on declarations could optimize this new case just as easily.
* Some implementations do microcode dispatch, so they don't have to
worry. Of the others, though, I'd bet most do a sequential type
dispatch that falls through to an error clause. If you put the
general array case right before the error clause, it's not costing
anyone but the people who want it (because they have to wade through
the other cases).
* Even so, since it's a constant-time operation to do this algorithm
selection and since all of these operations involve loops, the
performance hit even if you took one would be likely to get lost
in the dust.
* Touretzky effectively argues that there may be a speed improvement
because you can just check for type ARRAY and not check that it's
only a 1d array and go straight to business playing with its
elements. In some cases, this can speed things up by making it
possible to remove code that did what he is suggesting are
"gratuitous" error checks.
Pedersen: ... The truth is that if you really want to do
multi-dimensioned array manipulation, you really do want something
like APL, or close to it. Implementing an array calculus -- like APL
-- is quite doable ... and is the right way to go for heavy array users ...
Well, of course, Touretzky says outright in the proposal that he realizes
this is a harder problem and that he doubts that we would be interested
in solving that, but that the solution to the simpler problem would be
significantly interesting to him certainly and perhaps to others (a
claim that I think he gives a credible case for).
Moreover, the more interesting case is for people who are -not- heavy
array users. They just have one array and they're in some place where they
want to count certain elements. Having to write a routine to do this can
distract from the true purpose of the function, which may be unrelated
to the array issue.
I was recently looking back over a lot of old Maclisp code I wrote
around 1979-80. I was struck by the number of times I'd written utility
functions that got used only once -- many things that now are (fortunately)
available in the system. Getting up to a conversational level with Lisp
took most of the effort -- the programs were trivial by modern standards.
I had friends who wrote shorter (but I'd say less intelligible) programs
where they didn't take the time to abstract things out and so in the
middle of some program there'd be a couple of nested DO loops taking the
MAX of something which was not very relevant in the grand scale of things,
but which took up a lot of syntactic space.
I think it's reasonable for us to consider minor extensions that aid
this end of just making certain utilities be common so that they needn't
be written be written time and time again unnecessarily. I think this is
what Common Lisp is about.
∂01-May-87 1933 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 19:33:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 22:34:05-EDT
Date: Fri, 1 May 1987 22:34 EDT
Message-ID: <FAHLMAN.12299038089.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: Msg of 21 Apr 1987 15:51-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I have had applications which for various reasons I can't go
into in detail where I needed to have a keyword which no one
but myself would use.
Come on, doesn't anyone have a short, coherent example that demonstrates
the need for a non-keyword as a "keyword" argument? If the goal is to
have publically accessible functions that take hidden arguments, I'd
like to see an explanation of the need for this. Seems to me like a
pretty bogus way to do encapsulation, but maybe I'm missing something.
Testimonials are fine, but it's going to be hard to sell this proposal
without a coherent explanation.
-- Scott
∂01-May-87 1947 FAHLMAN@C.CS.CMU.EDU ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 19:47:18 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 22:48:23-EDT
Date: Fri, 1 May 1987 22:48 EDT
Message-ID: <FAHLMAN.12299040692.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
In-reply-to: Msg of 22 Apr 1987 16:51-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I don't like this proposed extension. It seems confusing and dangerous
to do the destructive operation in some cases and a copy in other cases.
I think that I would be more comfortable with some sort of COPY-ARRAY
function, though I'd need to see the details in order to be sure.
-- Scott
∂01-May-87 2030 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87 20:29:55 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130098; Fri 1-May-87 23:30:18 EDT
Date: Fri, 1 May 87 23:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299038089.BABYL@C.CS.CMU.EDU>
Message-ID: <870501233004.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I have a Version 2 of this issue waiting for Moon to look it over before sending it
out. The following text is excerpted from that proposal. Does it look any better
to you?
Rationale:
By allowing symbols other than keyword symbols as keywords, we provide
a more private communication channel between functions.
Also, applications such as the emerging object-oriented standard which
must reliably merge keywords coming from different sources (some internal
and some user-supplied) can work more reliably by exploting this new
partitioning of keyword names. For example, a public routine MAKE-FOO
might need to accept arbitrary keywords from the caller and might want
to pass those keywords along to an internal routine using keywords of
its own.
For example,
(IN-PACKAGE 'SYSTEM)
(DEFUN MAKE-INSTANCE (TYPE &REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-INSTANCE-INTERNAL TYPE 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would override
some keyword in keyword-value-pairs since the only way that could happen
is if someone had done (MAKE-INSTANCE 'ZEBRA 'SYSTEM::EXPLICIT NIL), or
if the user was programming explicitly in the SYSTEM package, either of
which is an implicit admission of willingness to violate SYSTEM's modularity.
∂01-May-87 2037 FAHLMAN@C.CS.CMU.EDU UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 20:37:07 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 23:26:54-EDT
Date: Fri, 1 May 1987 23:26 EDT
Message-ID: <FAHLMAN.12299047704.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
In-reply-to: Msg of 23 Apr 1987 02:07-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Larry's status report says that this issue has been agreed...
I never agreed to this, and I think you are overlooking something.
Well, it should have been "agreed by those present at the pre-X3J13
meeting", I guess.
Therefore I propose that case 1, transfer to a point inside the point to
which control would have transferred, not do the second throw. There
are two things we could require it to do instead (or we could just
wimping out and say it "is an error"). It could signal an error, or
it could resume the original throw, just as if the cleanup handler had
exited normally. I prefer signalling an error, because I firmly believe
that the program is ill-formed.
I think you've spotted a case that the rest of us missed. At least, it
didn't come up in earlier discussion. I'm not completely sure what is
right, but I'm inclined to agree that "signals an error" is the right
thing here, rather than just allowing the throw whose tag is outermost
to win. I've got a hunch that trying to do the latter would just
introduce another layer of subtle problems.
Note that signalling an error must
avoid the following pitfall once an error-handling facility is added to
Common Lisp:
(loop
(ignore-errors
(unwind-protect (loop)
(error))))
The illegal-nested-throw error must not be caught by ignore-errors or
nothing will have been solved.
I guess we need a class of errors that don't get ignored, despite the
user's instructions. There are probably some other members of this
class. Some asynchronous things that have nothing to do with the code
inside the IGNORE-ERRORS form might qualify: system almost out of
memory, memory error, and stuff like that.
-- Scott
∂01-May-87 2115 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 21:15:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 00:16:48-EDT
Date: Sat, 2 May 1987 00:16 EDT
Message-ID: <FAHLMAN.12299056786.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: Msg of 1 May 1987 23:30-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Yeah, that's the sort of example I was looking for. I see what you're
driving at now, but the example of Make-Instance doesn't seem terribly
compelling. One might question whether this is the best way, or even a
reasonable way, to pass this collection of stuff on to
Make-Instance-Internal. Why pass Explicit as a keyword at all? Why not
as a required arg, since the target function has to be ready to handle
Explicit in any event. Seems like you're just muddling things together
and that the callee will have to un-muddle them again.
In any event, I suppose that this is a legitimate style, even though I
think it is ugly and probably inefficient. Since the proposed change is
fairly harmless, this example probably provides enough motivation for it.
-- Scott
∂01-May-87 2128 FAHLMAN@C.CS.CMU.EDU Issue DEFVAR-INIT-TIME (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 21:27:55 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 00:29:01-EDT
Date: Sat, 2 May 1987 00:28 EDT
Message-ID: <FAHLMAN.12299059010.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue DEFVAR-INIT-TIME (Version 1)
In-reply-to: Msg of 23 Apr 1987 16:59-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
This looks OK to me.
I believe that the cause of the confusion is really the statement that
the initial value form is not evaluated unless "it is used". Better to
say that INITIAL-VALUE is evaluated if and only if the variable does not
already have a value. Then I think that there would be no confusion
about the time of evaluation, though it can't hurt to spell this out
explicitly.
-- Scott
∂01-May-87 2145 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87 21:44:57 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130133; Sat 2-May-87 00:45:09 EDT
Date: Sat, 2 May 87 00:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299056786.BABYL@C.CS.CMU.EDU>
Message-ID: <870502004454.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sat, 2 May 1987 00:16 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
... One might question whether this is the best way, or even a
reasonable way, to pass this collection of stuff on to
Make-Instance-Internal. Why pass Explicit as a keyword at all? Why not
as a required arg ...
What if MAKE-INSTANCE-INTERNAL takes 47 such internal keywords? Just
because I only used one in the call doesn't mean that's all it receives.
Would you have me pass all 47 internal arguments on every call?
Also, the caller of MAKE-INSTANCE might be within package SYSTEM and so
it might not be an abstraction violation for him to pass other packaged
symbols. That means that more keywords than those you see might be being
received in the main arglist, though presumably none that the caller
worries are going to be overridden by MAKE-INSTANCE.
Or there might be other situations in which keyword-style calling is
more important than in the particular call that you have there.
I could add some of these issues to the add rationale, too, if you like.
Almost by definition, any two-line example is not going to leave you
feeling satisfied about something which is claimed to be useful in
complex situations involving modularity boundaries.
Anyway, the fact that you can figure out what is being hinted at by the
small example makes me feel like the example did its job.
∂02-May-87 0707 FAHLMAN@C.CS.CMU.EDU DELETE, SORT, ADJUST-ARRAY considered harmful
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 07:07:29 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 10:08:35-EDT
Date: Sat, 2 May 1987 10:08 EDT
Message-ID: <FAHLMAN.12299164519.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@THINK.COM>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: DELETE, SORT, ADJUST-ARRAY considered harmful
In-reply-to: Msg of 25 Apr 1987 03:25-EDT from Guy Steele <gls at think.com>
Well, maybe the proposed syntax stinks, but perhaps some way of
idiot-proofing destructive operations should nevertheless be found.
Nothing is foolproof because fools are so ingenious. (Who said that?)
I don't think that it is a good idea to go back and diddle with these
old problems at this point. Destructive operations on lists are tricky
in N other ways as well, so you've got to stop and think. I wouldn't
mind a "chatty" compiler mode that warns of a possible problem whenever
it sees a DELETE not in a setting form, but this is not a standards-type
issue.
Since you signed this "Quux", I'll assume that you don't really want to
push it.
-- Scott
∂02-May-87 1143 FAHLMAN@C.CS.CMU.EDU IF-BODY (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 11:42:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 14:43:57-EDT
Date: Sat, 2 May 1987 14:43 EDT
Message-ID: <FAHLMAN.12299214648.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: IF-BODY (Version 5)
In-reply-to: Msg of 27 Apr 1987 18:21-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I hate to keep beating on this, but we're working on developing internal
procedures for handling controversial cases, and it probably is worth
trying to debug these procedures on a stupid case like this before
something really hard comes along. I think we've got the wrong model
here for dealing with controversial things. It is unreasonable to ask
one person to produce a balanced presentation that fairly summarizes all
points of view, including views that he disagrees with.
KMP's latest version of the IF-BODY proposal is a case in point. It
represents a good-faith attempt on his part to present a balanced
discussion of the issues, but the result is nevertheless unbalanced in
subtle ways toward his point of view. I'm not trying to dump on KMP
here -- if I had written the summary, I'm sure it would be even more
biased the other way.
KMP states at the outset that some implementations, if allowed to, will
implement this extension, and that these extended implementations will
"typically" not generate a warning. Later he argues that encouraging
(but not requiring) a warning is inadequate, because an implementation
that adds this feature must think it is a good idea, and you don't warn
about good ideas. This ignores the possibility of a "warn me about any
non-portable code" compilation mode, which is the right solution
(assuming this IF-BODY problem is troublesome enough that it is worth
fixing at all). If an implementor doesn't choose to support such a
mode, fine; that's between him and his customers. But don't ask the
rest of us to mess up the language in order to make that
implementation's users more comfortable -- if the vendor doesn't want to
employ the obvious simple technique for solving this problem, then it
presumably isn't worth solving. I've stated this view N times before
and this "somebody prepare a summary" process keeps eviscerating the
argument. Again, it is the process that is at fault, not the people
doing the summarizing.
It seems to me that the process should go something like this: Person X
proposes a compatible extension. If, after some discussion, consensus
is reached on some (possibly amended) version of the extension, we put
that version forward as a proposal, with some sort of joint rationale in
the discussion section. If the committee doesn't like the proposal and
can talk the proposer into dropping it, fine, we drop it. If there is
no consensus in favor of the change, but the proposer wants to present
the matter to the full X3J13, then he should prepare the most persuasive
argument he can muster -- none of this "balance" stuff. Then, in the
discussion section, the opposition gets to have its say. The point is
that each side of the case must be argued by someone who believes in it.
Just like the lawyers. I suppose that in some cases, there might be
more than one dissenting opinion: various people might dislike a
proposal for different reasons.
There remains the question of who gets the last word. We could iterate
until quiescence or exhaustion is reached, flip a coin, or establish
some arbitrary guideline. I guess I'd say that the proposer gets his
say, then the negative voices, and finally the proposer gets a short
rebuttal (confining himself to answering what the opposition said,
rather than introducing new arguments). The result is concatenated, not
summarized, for presentation to the outside world.
The above assumes that the question is whether or not we should adopt
some change. In a situation where there are N positive proposals to
choose from, all with their advocates, then a FOO:A, FOO:B, FOO:C
approach is appropriate. The arguments in favor of each position should
be presented by the advocates of that position, if any exist. In the
case of a yes/no question, it is silly to have separate FOO:YES and
FOO:NO proposals.
-- Scott
∂02-May-87 1220 FAHLMAN@C.CS.CMU.EDU SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 12:20:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 15:21:49-EDT
Date: Sat, 2 May 1987 15:21 EDT
Message-ID: <FAHLMAN.12299221539.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
In-reply-to: Msg of 28 Apr 1987 14:13-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I have no strong opinion on this proposal. It doesn't look to me like
it would add much confusion, it wouldn't be too hard to implement, and
apparently some people would find it useful. So I guess I'm mildly in
favor of either the GENERALIZE or the MODIFIED version.
I would not like to see this leave committee in the current format.
Maybe KMP, Touretzky, Rees, and anyone else who cares can work out a
single proposal that they all like. The paths not taken can be
mentioned in the discussion section.
I would like to encourage KMP to go ahead with a separate proposal for
ROW-MAJOR-SUBSCRIPTS (or whatever we end up calling it). Given that, I
think a version of POSITION that returns a single number for arrays is
probably the way to go, and users can then turn this into a subscript
list if they like. I have a mild aversion to getting a list from some
function that has heretofore always returned a number or NIL.
In choosing issues to introduce in the future, we probably should lean
toward doing clarifications first and saving extension for later.
-- Scott
∂02-May-87 1313 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 13:13:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:13:50-EDT
Date: Sat, 2 May 1987 16:13 EDT
Message-ID: <FAHLMAN.12299231012.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 28 Apr 1987 16:35-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
<Is JAR on CL-CLEANUP now? If not, we should all include him in the
address list while discussing this.>
I think that this proposal is confused. The current rule for handling a
reference to a variable that is neither bound nor declared is
unambiguous: the variable is assumed to be special. There is no
ambiguity and no need for clarification. Whether we want to change this
is another question, and an interesting one.
However, if you feed this program to many Common Lisp compilers
(including Symbolics's and DEC's), a warning message will be
produced for the SETQ, saying something like "Warning: X not
declared or bound, assuming special."
These warnings, unlike the annotations of undefined functions (which
occur only at the end of a compilation), are presented so
prominently that a user would be hard put to say that a program
which elicited such warning messages was "correct" in that
implementation. Unlike the situation with unused variables, there is
no possible declaration one can write which suppresses the warning
messages.
Not true. You can suppress this warning by saying (proclaim '(special
<var>)) or (defvar <var>).
In my view (the manual doesn't spell this out, so we rely on shared
culture) a Common Lisp compiler is free to issue a warning any time it
spots anything suspicious, even though the code may be legal. The more
of this a compiler does, the better it is as a debugging aid (up to the
point where the "crying wolf" effect sets in because too many spurious
warnings are being generated). The use of an undeclared variable is
legal because users like to do this in the interpreter; in a code file,
on the other hand, it is either very unstylish or, more likely, the
result of a typo. In the latter case, I want to see a warning. If you
tell me that I can can't use a warning here because it looks too much
like an error, then I'll have to create yet another kind of compiler
output ("mild suggestion?") with which I can report these things.
I prefer to retain the term warning for this, and to use the term "error"
when there really is an error.
If a fix really is needed here, it should probably be a compiler
declaration that suppresses all warnings in a certain stretch of code.
Then people who hate to see any warnings can get rid of them, and those
of use who use them for debugging can have them. But I see nothing
unacceptable or even uncomfortable about the status quo. Probably the
spec should explaint he difference between an error and a warning rather
than leaving this to the reader's imagination.
As a separate issue, we might want to try to hammer out a proposal for
what people have called "global lexicals", and we might even want to
make this the default for undeclared symbols used free. But we should
not muddle this into a discussion of the current rules or the difference
between warnings and errors in the compiler.
-- Scott
∂02-May-87 1324 FAHLMAN@C.CS.CMU.EDU FORMAT-OP-C (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 13:24:02 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:25:02-EDT
Date: Sat, 2 May 1987 16:24 EDT
Message-ID: <FAHLMAN.12299233050.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: FORMAT-OP-C (Version 2)
In-reply-to: Msg of 29 Apr 1987 12:38-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I support this proposl. I think that the presentation should be
simplified before it goes out. Most of the lengthy discussion in the
problem description is unnecessary. This is a simple clarification.
-- Scott
∂02-May-87 1340 FAHLMAN@C.CS.CMU.EDU PRINC-CHARACTER (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 13:30:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:31:09-EDT
Date: Sat, 2 May 1987 16:31 EDT
Message-ID: <FAHLMAN.12299234147.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: PRINC-CHARACTER (Version 2)
In-reply-to: Msg of 29 Apr 1987 15:46-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I favor PRINC-CHARACTER:WRITE-CHAR.
-- Scott
∂02-May-87 1616 JAR@AI.AI.MIT.EDU Is JAR on CL-CLEANUP now? Yes.
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 16:16:03 PDT
Date: Sat, 2 May 87 19:18:40 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Is JAR on CL-CLEANUP now? Yes.
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Sat 2 May 1987 16:13 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <194617.870502.JAR@AI.AI.MIT.EDU>
I'm on CL-CLEANUP.
∂02-May-87 1655 JAR@AI.AI.MIT.EDU Issue: PROCLAIM-LEXICAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 16:55:26 PDT
Date: Sat, 2 May 87 19:58:08 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Issue: PROCLAIM-LEXICAL
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Sat 2 May 1987 16:13 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <194629.870502.JAR@AI.AI.MIT.EDU>
Date: Sat, 2 May 1987 16:13 EDT
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Not true. You can suppress this warning by saying (proclaim '(special
<var>)) or (defvar <var>).
*Not* not true! Look again at the example. If you declare the variable
special, you will change the semantics of the program. In this example
you would also have to rename every X that's lexically bound; being an
extremely non-local transformation, this is unacceptable.
In my view (the manual doesn't spell this out, so we rely on shared
culture) a Common Lisp compiler is free to issue a warning any time it
spots anything suspicious, even though the code may be legal.
I basically agree with this, but you should note that every other sort
of warning is avoidable. E.g. an unreferenced bound variable is often a
result of a program error, but when it's not it can be dealt with by
(DECLARE (IGNORE ...)); an OR with only one subform can be a symptom of
a misplaced parenthesis, but where it's the right thing there are ways
to get around the problem (make your macros smarter...). But in this
case the only way to get rid of the warning is either by
alpha-converting or by making the program possibly incorrect, which is
definitely unfriendly.
I don't know how you develop code, but I like to get my programs into
a condition where they do not elicit warnings from the compiler.
The use of an undeclared variable is
legal because users like to do this in the interpreter; in a code file,
on the other hand, it is either very unstylish or, more likely, the
result of a typo.
Why is this any different from an undefined function, which is not
similarly warned about? I believe these two situations (forward
reference to a variable and to a function) should be treated
symmetrically.
If a fix really is needed here, it should probably be a compiler
declaration that suppresses all warnings in a certain stretch of code.
Unacceptable in this case (unless we adopt BY-THE-BOOK); many warnings
are quite desirable. I would say a warning is OK if either it indicates
that an error will happen at run time, or if the code is truly is dubious
style AND there is an easy way to fix or annotate the code so that the
warning goes away.
As a separate issue, we might want to try to hammer out a proposal for
what people have called "global lexicals", and we might even want to
make this the default for undeclared symbols used free.
If you look at the proposal carefully you'll see that it contains
exactly this; namely, in the GENERAL and RESTRICTED alternatives, you
can do (PROCLAIM '(LEXICAL ...)). I'm wondering how you missed it,
although if you only looked at the summary at the top and not the rest
of the message, that would explain it; the introduction is admittedly
misleading. I'll fix that next time around.
Like I said in the "Status:" line, this is very preliminary.
Jonathan
∂02-May-87 1720 FAHLMAN@C.CS.CMU.EDU Is JAR on CL-CLEANUP now? Yes.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 17:20:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 20:20:35-EDT
Date: Sat, 2 May 1987 20:20 EDT
Message-ID: <FAHLMAN.12299275925.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Is JAR on CL-CLEANUP now? Yes.
In-reply-to: Msg of 2 May 1987 19:18-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Good. Wasn't sure if you were seeing things routinely or if KMP was
just passing you selected tidbits.
-- Scott
∂02-May-87 1855 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87 18:55:47 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 21:56:52-EDT
Date: Sat, 2 May 1987 21:56 EDT
Message-ID: <FAHLMAN.12299293460.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 2 May 1987 19:58-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
In reply to JAR:
Not true. You can suppress this warning by saying (proclaim '(special
<var>)) or (defvar <var>).
*Not* not true! Look again at the example.
...
I don't know how you develop code, but I like to get my programs into
a condition where they do not elicit warnings from the compiler.
OK, if you really want to use the same names for your specials and your
lexicals, then indeed there is no good way to get rid of the warning. I
hardly ever do this, so I missed your point. When I see that warning in
a case like your example program, it tells me that it's time to rename
something, not that I should find some way to inhibit the warning with a
declaration.
I assume that we're not going to consider any radical proposals for the
handling of specials, such as separating the name spaces by making the
*foo* syntax mandatory for specials. If we stay close to the status
quo, it seems to me that we really should go ahead and add a LEXICAL
declaration and a LEXICAL proclamation so that those pervasive special
proclamations can be cancelled or shadowed. I haven't heard any good
arguments against this in the last N years. The need to eliminate
spurious "not declared or bound" warnings is one argument in favor of
this change, but it would be a useful change for other reasons in any
case.
Why is this any different from an undefined function, which is not
similarly warned about? I believe these two situations (forward
reference to a variable and to a function) should be treated
symmetrically.
No difference in principle. Both conditions are suspicious and worth a
warning, in my view, but how such warnings are handled is up to the
implementor. It is desirable to emit these warnings when the suspicious
condition is noticed; that way the location of the problem is marked and
the user has the option of aborting the compilation. In the case of
undefined functions, forward references are particularly common, so most
implementations wait till the end of the compilation before emitting the
warning. In the case of undeclared specials, there does not seem to be
a good reason to wait, so we warn at once.
As a separate issue, we might want to try to hammer out a proposal for
what people have called "global lexicals", and we might even want to
make this the default for undeclared symbols used free.
If you look at the proposal carefully you'll see that it contains
exactly this; namely, in the GENERAL and RESTRICTED alternatives, you
can do (PROCLAIM '(LEXICAL ...)). I'm wondering how you missed
it...
I didn't miss it. Your GENERAL and RESTRICTED proposals seem to re-open
a debate that we had some time ago on "global" or "global lexical"
variables and what their semantics should be. A lot of hairy issues
came up in that discussion, and I didn't see those issues being
addressed here. So my suggestion was that we ought to separate this
issue from the business about inhibiting warnings and try to come up
with a comprehensive proposal on global variables -- comprehensive in
the sense that we try to deal with all the issues raised in the earlier
discussion.
-- Scott
∂04-May-87 1056 Masinter.pa@Xerox.COM Issue priority
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 May 87 10:56:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAY 87 10:54:17 PDT
Date: 4 May 87 10:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue priority
to: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870504-105417-2905@Xerox>
We've been asked by some members of the object proposal to quickly
address the issues that they are waiting on.
Those issues include:
KEYWORD-ARGUMENT-NAME-PACKAGE
FUNCTION-TYPE
and an issue, currently not written up, on whether the types STREAM,
PACKAGE, PATHNAME, READTABLE and RANDOM-STATE can be required to be
disjoint from other types (e.g., as if they had been created with
DEFSTRUCT.)
I didn't see any strong objections to these proposals, except for the
way in which they were worded.
If you'd like to discuss any of these issues, you will make my life
simpler if you will send separate messages about each.
∂04-May-87 1423 KMP@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 May 87 14:23:05 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 131431; Mon 4-May-87 17:22:42 EDT
Date: Mon, 4 May 87 17:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: Fahlman@C.CS.CMU.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299047704.BABYL@C.CS.CMU.EDU>
References: The message of 23 Apr 1987 02:07-EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
The message of 29 Apr 1980 16:09-EDT from Jon L White <JONL at MIT-MC>
Message-ID: <870504172241.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 1 May 1987 23:26 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
In-reply-to: Msg of 23 Apr 1987 02:07-EDT
from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
...
Note that signalling an error must
avoid the following pitfall once an error-handling facility is added to
Common Lisp:
(loop
(ignore-errors
(unwind-protect (loop)
(error))))
The illegal-nested-throw error must not be caught by ignore-errors or
nothing will have been solved.
Personally, I consider the meaning of this to be well-formed. It'd be
sad for a programmer to get into this, but I think that in this case
the user has pretty clearly asked to have a loop that cannot be exited
and deserves to have that request carried out.
Consider how ridiculous it would have looked on Star Trek when they
needed to divert the computer's attention and said "Computer, compute to
the last digit the value of pi". If I recall, Spock makes a remark like
"As you know, the value of pi is a transcendental number without
resolution. ... The computer will work on this problem to the exclusion
of all else ...". Imagine how frustrated he'd have been if the computer
had refused to execute the command because it didn't seem like he really
meant what he said.
Well, ok, so this isn't the most likely scenario. But the truth is,
as Prof. Bill Martin said once in a linguistics class I took from him --
We create syntax in a language not to allow us to say the things that
are obvious, but so that we can say things that are not obvious. If we
didn't need to say things that were not obvious, we'd just jumble all
the words together and assume people would figure out some uniquely
determined, obviously useful interpretation. In fact, we make careful
rules to allow us to say bizarre things not so we can say bizarre things
all the time, but so that if there comes a time to say such things, we
won't be at a loss for words.
By the way, I did once write a CL program that wanted the semantics that
Moon claims are implausible. In Common Lisp, there was no portable way to
make a Lisp have a Macsyma toplevel (ie, where the vendor's abort character
would return me to Macsyma and not to Lisp). So I wrote something which did
effectively:
(DEFUN MACSYMA-TOPLEVEL ()
(PROG ()
LOOP (UNWIND-PROTECT (REALLY-MACSYMA-TOPLEVEL)
(GO LOOP))))
so that people who'd invoked Macsyma toplevel couldn't get back to toplevel
lisp. So while it might be rare, it's not unthinkable that someone could really
write this and mean what they said...
As such, I don't rate this desire to let the user intervene at the same
level of importance that Moon does. However, since I do find it an
interesting issue, I'm willing to entertain the issue for discussion
for now without prejudice to its ultimate importance.
I guess we need a class of errors that don't get ignored, despite the
user's instructions. There are probably some other members of this
class. Some asynchronous things that have nothing to do with the code
inside the IGNORE-ERRORS form might qualify: system almost out of
memory, memory error, and stuff like that.
If we did make this illegal, I'm curious exactly what Moon would want to
have happen here. The most plausible scenario I can come up with that fits
in this hypothetical framework is the following (which is essentially like
what Scott is suggesting) ...
THROW could notice that it was going to THROW to a point inside
a THROW which was already active. At this point, it could signal
a SERIOUS-CONDITION (some type which was not a subtype of ERROR),
so that IGNORE-ERRORS did not catch the condition, but that did
have a default handler that would force entry into the debugger.
This would allow an opportunity for user-intervention.
The debugger could offer options which should include:
* Going ahead with the inner THROW (and discarding the outer
THROW attempt).
* Exiting from this UNWIND-PROTECT cleanup body and continuing
the ongoing THROW.
* Blowing away the process without running its UNWIND-PROTECT
cleanups.
This would allow for user intervention without precluding what
I believe to be the clean semantics (choice C). I'm suspicious
of any choice which doesn't even allow the user to get style-C
semantics if that's what he wants.
Dave, is this the sort of thing you're proposing? If not, could
you please sketch what you are suggesting for contrast?
By the way, I ran across the following piece of mail the other day
while looking around for something else. I just thought you'd be
interested to know that this problem is as old as UNWIND-PROTECT
itself; the message is from only a few days after UNWIND-PROTECT
was first installed in Maclisp and although the bug is not like
the one we're discussing, the test scenario is a lot similar to
the code sketch Moon did above...
-----Forwarded Message Follows-----
Date: 29 April 1980 16:09-EDT
From: Jon L White <JONL at MIT-MC>
To: KMP at MIT-MC, RWK at MIT-MC
cc: BUG-LISP at MIT-MC
Subject: UNWIND-PROTECT
On the 15th of Feb, KMP sent out a bug notice about UNWIND-PROTECT
losing, for which I made the diagnosis that ERRSET was not saving
and restoring the UNREAL flag. The test case is
(DEFUN KMP-LOSES () (ERRSET (UNWIND-PROTECT NIL (OPEN '((DSK BOO) BAR BZ)))))
Well, I found a way to fix ERRSET without taking more pdl locations,
and the assembled code (already initialized) is on LISP;BBLISP 995QIO.
...
∂04-May-87 1919 FAHLMAN@C.CS.CMU.EDU Issue priority
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 May 87 19:19:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 4 May 87 22:18:19-EDT
Date: Mon, 4 May 1987 22:18 EDT
Message-ID: <FAHLMAN.12299821653.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue priority
In-reply-to: Msg of 4 May 1987 13:56-EDT from Masinter.pa at Xerox.COM
KEYWORD-ARGUMENT-NAME-PACKAGE
I believe that KMP is working on a version that explains why a change is
needed. The lack of such an explanation was my only real objection.
FUNCTION-TYPE
On my queue, but I've got a funding proposal to get out by the end of
the week, so this stuff won't get worked on until next weekend. If
anyone else can grab it sooner, feel free.
and an issue, currently not written up, on whether the types STREAM,
PACKAGE, PATHNAME, READTABLE and RANDOM-STATE can be required to be
disjoint from other types (e.g., as if they had been created with
DEFSTRUCT.)
I don't think we currently require structures to be a disjoint
type from vectors, etc., though this has been talked about. So that
should be part of any proposal.
∂05-May-87 1416 pedersen.pa@Xerox.COM Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 May 87 14:15:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 MAY 87 14:15:02 PDT
Date: 5 May 87 14:14 PDT
From: pedersen.pa@Xerox.COM
Subject: Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 1 May 87 19:56 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: Masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu,
Dave.Touretzky@C.CS.CMU.EDU, Pedersen.pa@Xerox.COM
Message-ID: <870505-141502-1099@Xerox>
Pitman:
"Actually, I bet some people don't ever used displaced-arrays because
they seem like excess hair and/or because the side-effect consequences
are hard to learn about. ... Displaced arrays may be taught in some
thorough
courses and one or two advanced books, but I bet are largely
overlooked...
Not to mention the fact that they inherently seem to violate an
abstraction and some people might avoid them because of some feel that
programs which use them are not clean."
I find a certain inconsistency in your argument that constructing
displaced-arrays is obtuse and unesthetic, while at the same time
stating that multi-dimensional arrays are naturally operated on as
vectors with elements laid out in row-major order. After all,
displaced-arrays are the only mechanism in common lisp that allows one
to adopt that view, and as such are indispensible. Indeed, one might
argue that for the inexperienced Lisp user, who has some knowledge of
"C" or "FORTRAN", displaced-arrays map directly into conventional use of
pointers into arrays.
On a more constructive note -- it seems like a small addition to the
array mechanism might address most of our concerns. Consider:
(defun flatten-array (array)
(cond ((vectorp array) array)
((arrayp array)
(make-array (array-total-size array)
:element-type (array-element-type array)
:displaced-to array))
(t (error "Not an array: ~s" array))))
then "flatten-array" may be used in combination with sequence functions
to achieve the desired semantics, and would have the advantage of making
clear the intention of a code fragment. A primitive like "flatten-array"
is useful in other contexts as well, and would complement a
"row-major-aref" primitive.
J.P.
∂10-May-87 1154 FAHLMAN@C.CS.CMU.EDU [RAM: exiting from unwind protects]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 May 87 11:54:48 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 May 87 14:54:06-EDT
Date: Sun, 10 May 1987 14:54 EDT
Message-ID: <FAHLMAN.12301313646.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [RAM: exiting from unwind protects]
I find the following pretty persuasive...
Date: Saturday, 2 May 1987 11:16-EDT
From: Rob MacLachlan <RAM>
To: fahlman
Re: exiting from unwind protects
ReSent-Date: Sun 10 May 87 10:56:56-EDT
ReSent-From: Rob.MacLachlan@C.CS.CMU.EDU
ReSent-To: fahlman@C.CS.CMU.EDU
ReSent-Message-ID: <12301270482.15.RAM@C.CS.CMU.EDU>
I don't really agree with Moon about this thing. I certainly knew about
about the feature of being about to write something that you can't exit
from using any common lisp facility, but I don't see this as a
"serious environment bug". Our system has always has this property.
When someone first pointed out this property of Common Lisp way back
when, I did in fact write the pathological example and it did in fact
behave in the pathological fashion. After a while I got bored of
trying to throw out of the break loop, and I quit.
If I had really been doing anything, I could always have skipped over
the losing frame using debug-return. Environment problems can have
environment solutions. In any case, I could have saved work I was
doing from the break loop. This feature certainly isn't a big deal;
there are lots of ways a malicious Lisp user can blow the system out
of the water. What happened the last time you did
(makunbound '*terminal-io*)?
In contrast, it seems to me that all the "fixes" for this problem
result in substantial increases in the complexity of the language
defintion for no gain. It seems that Moon has already introduced
three new things into the language:
1] The concept of "throwing out of an unwind protect cleanup". When
are you in an unwind protect? What does it mean to throw out of
it? Does this apply to lexical exits too? Does this signal an
error?
(block block
(unwind-protect <foo>
(return-from block)))
Does this?
(unwind-protect <foo>
(block block
(return-from block)))
2] The concept of errors that aren't errors, which we need so that
users can't screw themselves with this feature no matter how hard
they try.
3] The implicit requirement that an implementation have some exit
mechanism other than throw so that it can unwind out of cleanup
forms even if the user can't. What does the system do when you
are running in an unwind protect and the user types an interrupt?
In fact, it seems that Moon is being inconsistent here, since he
has already assumed that interrupts do throw. If the user
interrupts when running in a cleanup do you signal an error, and
then signal an error whenever the user tries to abort out of the
debugger?
If I had ever been screwed by this, I would think differently. I'm
sure that most of the reason that this problem doesn't happen is that
people usually don't write code that aborts from unwind protect
cleanups. There is a big difference between saying that something is
rarely needed and possibly dangerous and saying that it must signal an
error.
I am convinced that the simplest evaluation model is to say that the
unwind-protect cleanup is evaluated in the lexical and dynamic
environment of the unwind-protect form. Any alternative must somehow
introduce an "in an unwind protect cleanup" marker into the dynamic
environment of the cleanup forms.
Rob
∂11-May-87 1051 RPG Draft of revised FUNCTION-TYPE
∂10-May-87 1852 FAHLMAN@C.CS.CMU.EDU Draft of revised FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 May 87 18:52:19 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 May 87 21:51:36-EDT
Date: Sun, 10 May 1987 21:51 EDT
Message-ID: <FAHLMAN.12301389651.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: rpg@SAIL.STANFORD.EDU
Cc: masinter.pa@XEROX.COM
Subject: Draft of revised FUNCTION-TYPE
Dick,
I said I'd give you a shot at this before sending it to the whole
Cleanup list. Want to make a pass and see if this captures what we all
agreed to. I'm not too confident of my ability to use the right terms
for these lexical variables and things, so please keep an eye out for
that. I'm CC'ing Masinter just so he'll know that progress is
progressing progressively. It would be good to get thsi out within a
few days, since the CLOS people seem to need this to be settled.
-- Scott
---------------------------------------------------------------------------
To: cl-cleanup at SAIL.STANFORD.EDU
Re: Issue: FUNCTION-TYPE (version 3)
Status: Revised by SEF to reflect intensive discussions prior to the
last X3J13 meeting.
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by SEF 10-May-83
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function type into the CLOS class hierarchy.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Proposal FUNCTION-TYPE:REDEFINE
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.
2. The behvior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. The descriptions of FUNCALL, APPLY, MAPCAR and all functions in
Common Lisp which take functional arguments are modified to clarify that
they will take either functions, symbols, or lists that represent
lambda-expressions. A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this leaves the behavior of FUNCALL, APPLY, MAPCAR,
et al. unchanged, but that their descriptions must be changed to
accommodate the new definition of the FUNCTION type.
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Change this to the following:
If COMPILE is called with no definition supplied, then it will attempt
to compile the current global definition of the symbol <name>, and will
signal an error if it is unable to do so. In some implementations, an
interpeted function can be compiled individually only if it contains no
references to lexical context outside the function definition. If the
symbol's definition is already compiled, no error is signalled. An
implemenation may choose to recompile the function if the original
interpreted form is available; otherwise, this is a no-op.
Rationale:
This change gives a clean, useful definition to the FUNCTION data type in
Common Lisp and the related type predicates. Under the current
definition, FUNCTIONP is nearly useless, since it is defined to be true
of all symbols, including those that do not have functional definitions.
Current Practice:
Many programmers find it necessary to write their own predicate
corresponding to the new form of FUNCTIONP.
Adoption Cost:
The type predicates would of course have to be brought into compliance
with this proposal, but that should require little effort.
Compiled functions are true functions in almost all implementations,
but, in some implementations, interpreted functions and closures are
represented as lists. This would have to be changed in the interpreter,
FUNCALL, APPLY, and other places.
Benefits:
By resurrecting FUNCTION as a useful concept, this proposed change will
eliminate a lot of confusion and will make it easier to talk about
situations in which (true) functions are passed around as Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme and other
Lisp-1 dialects.
Conversion Cost:
This proposal attempts to minimize the impact on user code by allowing
APPLY, FUNCALL, and related functions to accept symbols and lambda
lists, as they currently do. The only impact on user-level code should
be a change in the operation of certain type predicates, and such cases
should be relatively easy to find and fix.
Aesthetics:
Making the concept of a function well-defined will probably be perceived
as a simplification.
It would be cleaner to require all functional arguments to be true
functions, eliminating the use of symbols and lambda-lists in this
context. However, in this case we felt that the simplification was not
worth a major incompatible change.
Discussion:
The original form of this proposal suggested that APPLY and friends
should take only true functions as the functional argument. The
current proposal was agreed to after a discussion of the conversion
problems that such an incompatible change might entail.
Some committee members have argued for an APPLICABLE-P predicate that
would be true of all objects that can be passed as the functional
argument to APPLY and friends: true functions, lambda lists, and symbols
that are FBOUNDP. I (sef) believe that this is not terribly useful and
can easily be defined by any user who wants it (or something similar).
In any event, this can be handled in a separate proposal.
fahlman@c.cs.cmu,masinter.pa@xerox/su
Function Type Proposal
I think it looks good as you have it. Fire away.
-rpg-
∂11-May-87 1256 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 12:56:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 15:55:55-EDT
Date: Mon, 11 May 1987 15:55 EDT
Message-ID: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (version 3)
Status: Revised by SEF to reflect intensive discussions prior to the
last X3J13 meeting.
Issue: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by SEF 10-May-83
Problem Description:
The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions. The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner. This would also make it easier
to integrate the function data type into the CLOS class hierarchy.
The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.
Proposal FUNCTION-TYPE:REDEFINE
1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination. The list form of the
FUNCTION type specifier may still be used only for declaration.
Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.
The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint. In particular, a list may not be used to implement
any FUNCTION subtype.
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.
2. The behvior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)). In particular, FUNCTIONP is no
longer true of symbols and lambda lists.
3. The descriptions of FUNCALL, APPLY, MAPCAR and all functions in
Common Lisp which take functional arguments are modified to clarify that
they will take either functions, symbols, or lists that represent
lambda-expressions. A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used. Note that this leaves the behavior of FUNCALL, APPLY, MAPCAR,
et al. unchanged, but that their descriptions must be changed to
accommodate the new definition of the FUNCTION type.
4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION. It is an error to use
the special form FUNCTION on a symbol that does not denote a function in
the lexical environment in which the special form appears.
Specifically, it is an error to use the FUNCTION special form on a
symbol that denotes a macro or special form. (Some implementations may
choose not to signal this error for performance reasons.)
5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION). It is an error to call SYMBOL-FUNCTION on anything
else. In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.
It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value). Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.
6. The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Change this to the following:
If COMPILE is called with no definition supplied, then it will attempt
to compile the current global definition of the symbol <name>, and will
signal an error if it is unable to do so. In some implementations, an
interpeted function can be compiled individually only if it contains no
references to lexical context outside the function definition. If the
symbol's definition is already compiled, no error is signalled. An
implemenation may choose to recompile the function if the original
interpreted form is available; otherwise, this is a no-op.
Rationale:
This change gives a clean, useful definition to the FUNCTION data type in
Common Lisp and the related type predicates. Under the current
definition, FUNCTIONP is nearly useless, since it is defined to be true
of all symbols, including those that do not have functional definitions.
Current Practice:
Many programmers find it necessary to write their own predicate
corresponding to the new form of FUNCTIONP.
Adoption Cost:
The type predicates would of course have to be brought into compliance
with this proposal, but that should require little effort.
Compiled functions are true functions in almost all implementations,
but, in some implementations, interpreted functions and closures are
represented as lists. This would have to be changed in the interpreter,
FUNCALL, APPLY, and other places.
Benefits:
By resurrecting FUNCTION as a useful concept, this proposed change will
eliminate a lot of confusion and will make it easier to talk about
situations in which (true) functions are passed around as Lisp objects.
By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes. It
also brings Common Lisp into closer alignment with Scheme and other
Lisp-1 dialects.
Conversion Cost:
This proposal attempts to minimize the impact on user code by allowing
APPLY, FUNCALL, and related functions to accept symbols and lambda
lists, as they currently do. The only impact on user-level code should
be a change in the operation of certain type predicates, and such cases
should be relatively easy to find and fix.
Aesthetics:
Making the concept of a function well-defined will probably be perceived
as a simplification.
It would be cleaner to require all functional arguments to be true
functions, eliminating the use of symbols and lambda-lists in this
context. However, in this case we felt that the simplification was not
worth a major incompatible change.
Discussion:
The original form of this proposal suggested that APPLY and friends
should take only true functions as the functional argument. The
current proposal was agreed to after a discussion of the conversion
problems that such an incompatible change might entail.
Some committee members have argued for an APPLICABLE-P predicate that
would be true of all objects that can be passed as the functional
argument to APPLY and friends: true functions, lambda lists, and symbols
that are FBOUNDP. I (sef) believe that this is not terribly useful and
can easily be defined by any user who wants it (or something similar).
In any event, this can be handled in a separate proposal.
∂11-May-87 1420 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 14:20:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137159; Mon 11-May-87 17:18:50 EDT
Date: Mon, 11 May 87 17:18 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-ID: <870511171840.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 11 May 1987 15:55 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Edit History: Version 1 by RPG 02/26/87
Version 2 by cleanup committee 15-Mar-87
Version 3 by SEF 10-May-83
I (apparently somewhat belatedly!) approve of FUNCTION-TYPE:REDEFINE
except with the following two caveats:
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.
Common Lisp currently defines a type-specifier named COMPILED-FUNCTION.
Is this a proposal to remove it? I would probably support such a proposal,
but it should be explicit.
If COMPILE is called with no definition supplied, then it will attempt
to compile the current global definition of the symbol <name>, and will
signal an error if it is unable to do so. In some implementations, an
interpeted function can be compiled individually only if it contains no
references to lexical context outside the function definition. If the
symbol's definition is already compiled, no error is signalled. An
implemenation may choose to recompile the function if the original
interpreted form is available; otherwise, this is a no-op.
The phrase "signal an error if it is unable to do so" is new. My
problem is that the concept of "unable to compile" is not defined and is
open to varying interpretations. For example, does this mean that if
any compiler warnings are issued, COMPILE should signal an error at the
conclusion of the compilation? Also, if we assume that the word
"should" used on CLtL p.439 is covered by the discussion of "must" on
CLtL p.6, then right now this "is an error" rather than "signals an
error." Also, the specification that COMPILE is a no-op if called with
one argument and the symbol's definition is already compiled appears to
be a change from CLtL, although CLtL is so ambiguous it's hard to be
sure.
Unless there are reasons that these changes to COMPILE must be
incorporated into this proposal, I think it would be better to deal with
them as a separate proposal. For this proposal, I suggest confining the
discussion to how COMPILE defaults its second argument. I would say
that if the second argument is not supplied, the first argument "should"
be a symbol that is FBOUNDP and for which the implementation is able to
reconstruct the lambda-expression corresponding to its definition. So
the only change from CLtL would be to change "a definition that is a
lambda-expression" to "a definition from which the implementation is
able to reconstruct a lambda-expression". Possibly we should try to state
some necessary conditions under which the implementation is required to
be able to recover the lambda-expression. Possibly we shouldn't; this
only points out the inherent uselessness of 1-argument COMPILE in
portable programs.
Alternatively, we could take the coward's way out and make both
arguments to COMPILE be required, or, even better, make COMPILE take
only one argument, which must be a lambda expression, and neither read
nor write SYMBOL-FUNCTION.
∂11-May-87 1443 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 14:41:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137185; Mon 11-May-87 17:39:09 EDT
Date: Mon, 11 May 87 17:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: PATHNAME-STREAM
Status: New issue, but easy to agree on
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
OPEN (p.418), WITH-OPEN-FILE (p.422),
RENAME-FILE (p.423), DELETE-FILE (p.424)
Category: CHANGE/CLARIFICATION
Problem Description:
The PATHNAME function as documented in CLtL is impossible to implement.
The book says that a stream can be used as an argument and converted to
a pathname, but pathnames only name files, not other sources or sinks
of data that streams might be connected to.
Proposal PATHNAME-STREAM:FILES-ONLY:
Specify that if a stream is used as a pathname, it must be a stream
that is or was open to a file.
Rationale:
This is probably what the designers of Common Lisp intended.
This is the only thing that can be implemented without large changes to
the language such as extending pathnames to things other than files.
Current Practice:
Some systems signal an error if a non-file stream is used as a pathname.
Others may do something else, but since the proposal is to define this
to be "is an error", current practice seems irrelevant.
Adoption Cost:
Since I didn't say "signals an error", no implementations need change.
Benefits: Description of pathname functions will make more sense.
Conversion Cost: None.
Aesthetics: Makes language a little cleaner.
Discussion: None yet.
∂11-May-87 1502 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 15:02:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137213; Mon 11-May-87 18:01:19 EDT
Date: Mon, 11 May 87 18:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: PATHNAME-SYMBOL
[Note that this is not the same issue as PATHNAME-STREAM]
Status: New issue
References: PATHNAME (p.413), also the introductory text right above
it on the same page.
Derived references: PARSE-NAMESTRING (p.414),
MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
NAMESTRING etc. (p.417).
Category: INCOMPATIBLE CHANGE
Problem Description:
Some Common Lisp functions are specified to accept a symbol where a
pathname is expected. Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE,
and RENAME-FILE) are not specified to accept a symbol.
Proposal PATHNAME-SYMBOL:NO
Never allow symbols where pathnames are expected.
Rationale:
The feature of accepting a symbol was copied by Common Lisp from Zetalisp,
which in turn copied it from Maclisp. The reason Maclisp allowed a symbol
here was that it did not have strings at all. However, the feature has been
long since removed from Zetalisp, since it was found to be a source of bugs
and not to be useful. I suspect this feature was removed from Zetalisp
before Common Lisp was defined, but due to the poor state of Zetalisp
documentation at the time the change was overlooked by the designers of
Common Lisp.
One example of the type of bug caused by this occurs when NIL is erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find a
table entry that was expected to exist and returned -false-. In systems
that accept symbols as pathnames, this causes a reference to a file named
"nil" on some perhaps unexpected directory.
Current Practice:
Varies. Some implementations allow symbols here, some don't. Symbolics
doesn't allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES,
and allowing them there is probably a bug in the implementation.
Adoption Cost:
It's easy to change implementations to stop accepting symbols. Since this
appears to be an "is an error" rather than "signals an error" situation,
no implementation change is actually necessary.
Benefits:
Pathname functions will be more consistent. In implementations that check
the type of this argument, program error checking will be improved.
Conversion Cost:
Some users might be using symbols as pathnames, in implementations where
that works, and they would have to switch to using strings.
Aesthetics: Improved by the change.
Discussion:
The only user feedback on this issue I've seen was a bug report that
MERGE-PATHNAMES was in error because it accepted symbols.
∂11-May-87 1803 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-SYMBOL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 18:03:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 21:02:25-EDT
Date: Mon, 11 May 1987 21:02 EDT
Message-ID: <FAHLMAN.12301642842.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: PATHNAME-SYMBOL
In-reply-to: Msg of 11 May 1987 18:01-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I favor PATHNAME-SYMBOL:NIL.
It would be nice if someone would undertake a complete review of the
pathname situation. Seems to me that many problems lurk in here. But
the desire for a comprehensive solution shouldn't prevent us from
patching things that need to be patched.
-- Scott
∂11-May-87 1807 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-STREAM
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 18:05:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 21:04:29-EDT
Date: Mon, 11 May 1987 21:04 EDT
Message-ID: <FAHLMAN.12301643218.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: PATHNAME-STREAM
In-reply-to: Msg of 11 May 1987 17:39-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I favor PATHNAME-STREAM:FILES-ONLY.
-- Scott
∂11-May-87 1901 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 19:01:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137484; Mon 11-May-87 21:59:47 EDT
Date: Mon, 11 May 87 21:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511215932.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: KEYWORD-ARGUMENT-NAME-PACKAGE
References: Lambda Expressions (pp60-64)
Category: CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
29-Apr-87, Version 2 by Pitman
11-May-87, Version 3 by Moon
Status: Revised after discussion
Problem Description:
CLtL says that only keyword symbols can be used as non-positional argument
names in &key parameter specifiers.
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)
Remove restrictions on the package of non-positional argument names;
allow any symbol, including NIL.
Rationale:
As Common Lisp is currently defined, if someone wants to define a function
that accepts named (rather than positional) arguments whose names are
symbols in packages other than the KEYWORD package, they cannot use &KEY.
Instead, they have to duplicate the &KEY mechanism using &REST, GETF,
and (if they want error checking of argument names) DO. This suggests that
the restriction of &key to only keyword symbols is arbitrary and unnecessary.
Note that the "rationale" box on p.62 of Common Lisp: the Language is an
argument in favor of requiring non-positional argument names to be symbols,
and not allowing numbers, but does not speak to the issue of whether or not
those symbols should be further restricted to be keywords.
The desire for non-positional arguments whose names are not keyword symbols
arises when the set of non-positional arguments accepted by a function is
the union of the sets of non-positional arguments accepted by several other
functions, rather than being enumerated in a single place. In this case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.
One example of a Common Lisp application that requires this capability is
the draft proposal for an object-oriented programming standard. It will
have generic functions that accept non-positional arguments and pass them on
to one or more applicable methods, with each method defining its own set of
arguments that it is interested in. If this proposal is not adopted, either
the non-positional argument names will be required to be keywords, which
will require the methods to have non-modular knowledge of each other in
order to avoid name clashes, or the methods will have to be defined with an
ad hoc mechanism that duplicates the essential functionality of &key but
removes the restriction.
A second example of a Common Lisp application that requires this capability
is private communication channels between functions. Suppose a public
routine MAKE-FOO needs to accept arbitrary keywords from the caller and
passes those keywords along to an internal routine using keywords of its
own.
(IN-PACKAGE 'FOOLAND)
(DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
(APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would override
some keyword in keyword-value-pairs, since the only way that could happen is
if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL), or if the user was
programming explicitly in the FOOLAND package, either of which is an implicit
admission of willingness to violate FOOLAND's modularity.
Documentation Impact:
The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in understanding
the impact of the proposal.
Change wording which refers to non-positional arguments as being introduced
by keyword symbols to simply refer to those arguments being introduced by
symbols. For example, in the middle of p.60, the sentence:
... each -keyword- must be a keyword symbol, such as :start.
would become
... each -keyword- must be a symbol.
Also, the word "keyword" in the first complete sentence on p.62 would
be changed to "symbol" for similar reasons.
Add extra wording on p.60 to explain that by convention keyword symbols
are normally used as non-positional argument names, and that all functions
built into the Common Lisp language follow that convention. A language
manual might or might not choose to describe the circumstances in which
it is appropriate not to follow this convention.
Add examples to illustrate this behavior. For example, on p.64 the
following examples might be added:
((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
=> (1 2 6 NIL)
((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
=> (1 2 6 NIL)
Current Practice:
We do not currently know of an implementation that enforces the restriction
that this proposal seeks to remove.
Some implementations have bugs that prevent NIL from working as a keyword
argument name, but allow all non-NIL symbols. (One Symbolics version that
was checked had this bug.)
Adoption Cost:
No existing programs will stop working. Some implementors might have to
rearrange their error checking slightly, but it should be very easy.
Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.
Benefits:
This will help with the object-oriented programming standard, among other
things.
Conversion Cost:
None.
Aesthetics:
There will probably be an argument about whether the restriction is
more esthetic or less esthetic than the freedom, but in either case
the aesthetic effect is slight.
In any case, users who do not want to use the extended functionality
can generally avoid it.
Discussion:
Moon generated the original version of this proposal and supports it.
He thinks that if Common Lisp truly has a restriction that only keyword
symbols can be used as keyword names in calls to functions that take
keyword arguments, it will be more difficult to come up with an
object-oriented programming standard that fits within Common Lisp.
Pitman supports this proposal.
There was some question in the committee about whether the rationale
for the proposal was believable. I hope this version of the proposal
has resolved any doubts.
∂11-May-87 1907 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87 19:07:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137493; Mon 11-May-87 22:05:42 EDT
Date: Mon, 11 May 87 22:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301642842.BABYL@C.CS.CMU.EDU>
Message-ID: <870511220522.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 11 May 1987 21:02 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I favor PATHNAME-SYMBOL:NIL.
To avoid any confusion: do you mean PATHNAME-SYMBOL:NO, or is
PATHNAME-SYMBOL:NIL a different proposal?
∂11-May-87 1940 FAHLMAN@C.CS.CMU.EDU Issue: PATHNAME-SYMBOL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87 19:40:23 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 22:39:37-EDT
Date: Mon, 11 May 1987 22:39 EDT
Message-ID: <FAHLMAN.12301660525.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: PATHNAME-SYMBOL
In-reply-to: Msg of 11 May 1987 22:05-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Clarification:
I favor PATHNAME-SYMBOL:NO.
-- Scott
∂12-May-87 0728 FAHLMAN@C.CS.CMU.EDU Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87 07:28:09 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 12 May 87 10:27:27-EDT
Date: Tue, 12 May 1987 10:27 EDT
Message-ID: <FAHLMAN.12301789389.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
In-reply-to: Msg of 11 May 1987 21:59-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
The rationale is now sufficient, and I support
KEYWORD-ARGUMENT-NAME-PACKAGE:ANY in general.
To prevent confusion, thr proposal should address the lambda-list syntax
explicitly. In order to write the next paragraph without going
insane, I will use the term "keyword-symbol" for a symbol whose home is
the keyword package, and "keyword-indicator" for the thing (which may or
may noit be a keyword-symbol) that appears in a function call to
specify a not-by-position argument.
If, following an &key, a variable appears alone and not as part of a
(keyword-indicator variable) pair, the behavior specified in CLtL is
unchanged: a keyword-symbol with the same print name as the variable is
created and is used as the keyword-indicator in function calls. The
only way to get a keyword-indicator that is not a keyword-symbol is to
use the (keyword-indicator variable) syntax in the function's lambda
list. Note that the variable must not be a constant, but that the
keyword-indicator may be.
Obviously, if we had anticpated this change, we should have called
keyword arguments something else, but it is too late now.
One last comment: if it were up to me, I would exclude NIL as a legal
keyword-indicator. Nobody would ever want to use this -- it doesn't
help at all in solving the kinds of encapsulation problems discussed in
the rationale -- and allowing this is particularly likely to mask errors
made by the user. If it screws some current implementations, that's
another (weak) reason to disallow this. I don't want to fight about
this, but if NIL is allowed, I might fix our compiler to warn
about this as being "technically correct but probably a bug".
-- Scott
∂12-May-87 0930 Gregor.pa@Xerox.COM Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 09:30:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 MAY 87 09:26:41 PDT
Date: 12 May 87 09:24 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 11 May 87 21:59 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <870512-092641-3405@Xerox>
I support KEYWORD-ARGUMENT-NAME-PACKAGE:ANY.
∂12-May-87 1158 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87 11:58:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138111; Tue 12-May-87 14:56:28 EDT
Date: Tue, 12 May 87 14:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301789389.BABYL@C.CS.CMU.EDU>
Message-ID: <870512145619.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 12 May 1987 10:27 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
The rationale is now sufficient, and I support
KEYWORD-ARGUMENT-NAME-PACKAGE:ANY in general.
Thanks.
To prevent confusion, thr proposal should address the lambda-list syntax
explicitly. In order to write the next paragraph without going
insane, I will use the term "keyword-symbol" for a symbol whose home is
the keyword package, and "keyword-indicator" for the thing (which may or
may not be a keyword-symbol) that appears in a function call to
specify a not-by-position argument.
I was using "non-positional-argument-name" where you used "keyword-indicator".
We have to do something about the terminology. I like "argument name" a little
better than "keyword indicator", although the former has the problem that people
might confuse it with "parameter name", since experience has shown that it's
virtually impossible for anyone to remember which are the arguments and which
are the parameters.
If, following an &key, a variable appears alone and not as part of a
(keyword-indicator variable) pair, the behavior specified in CLtL is
unchanged: a keyword-symbol with the same print name as the variable is
created and is used as the keyword-indicator in function calls. The
only way to get a keyword-indicator that is not a keyword-symbol is to
use the (keyword-indicator variable) syntax in the function's lambda
list. Note that the variable must not be a constant, but that the
keyword-indicator may be.
I agree with this, except that the syntax actually has two parentheses,
i.e. ((keyword-indicator variable)), to distinguish it from (variable default).
Obviously, if we had anticpated this change, we should have called
keyword arguments something else, but it is too late now.
We can take "lambda-list-keywords", which aren't "keyword-symbols" either,
as a precedent.
One last comment: if it were up to me, I would exclude NIL as a legal
keyword-indicator. Nobody would ever want to use this -- it doesn't
help at all in solving the kinds of encapsulation problems discussed in
the rationale -- and allowing this is particularly likely to mask errors
made by the user. If it screws some current implementations, that's
another (weak) reason to disallow this. I don't want to fight about
this, but if NIL is allowed, I might fix our compiler to warn
about this as being "technically correct but probably a bug".
I don't care about NIL being allowed or disallowed. As a language
designer, it seems like a weird restriction to disallow it, even though
there is no earthly reason to use it. As a commercial vendor, I won't
complain if we don't have to fix the bug that we currently disallow it.
I'll defer to anyone who has a strong opinion about this.
∂12-May-87 1258 gls@Think.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 12:57:56 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 15:59:54 EDT
Date: Tue, 12 May 87 15:59 EDT
From: Guy Steele <gls@Think.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: Fahlman@c.cs.cmu.edu, CL-Cleanup@sail.stanford.edu
In-Reply-To: <FAHLMAN.12299221539.BABYL@C.CS.CMU.EDU>
Message-Id: <870512155947.2.GLS@BOETHIUS.THINK.COM>
Date: Sat, 2 May 1987 15:21 EDT
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
...
I would like to encourage KMP to go ahead with a separate proposal for
ROW-MAJOR-SUBSCRIPTS (or whatever we end up calling it). Given that, I
think a version of POSITION that returns a single number for arrays is
probably the way to go, and users can then turn this into a subscript
list if they like. I have a mild aversion to getting a list from some
function that has heretofore always returned a number or NIL.
In this instance, note that a NIL result could be confused with an
empty list of subscripts, the natural result in the case of a
zero-dimensional array.
--Guy
∂12-May-87 1430 gls@Think.COM Issue: FUNCTION-TYPE (version 3)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 14:29:52 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:31:34 EDT
Date: Tue, 12 May 87 17:31 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: Fahlman@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-Id: <870512173129.7.GLS@BOETHIUS.THINK.COM>
I support FUNCTION-TYPE:REDEFINE.
∂12-May-87 1456 gls@Think.COM Issue: PATHNAME-SYMBOL
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 14:56:02 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:58:18 EDT
Date: Tue, 12 May 87 17:58 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PATHNAME-SYMBOL
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870512175812.2.GLS@BOETHIUS.THINK.COM>
I favor PATHNAME-SYMBOL:NO.
∂12-May-87 1457 gls@Think.COM Issue: PATHNAME-STREAM
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87 14:56:55 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:59:14 EDT
Date: Tue, 12 May 87 17:59 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PATHNAME-STREAM
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870512175910.3.GLS@BOETHIUS.THINK.COM>
I favor PATHNAME-STREAM:FILES-ONLY.
∂12-May-87 2104 Moon@STONY-BROOK.SCRC.Symbolics.COM [RAM: exiting from unwind protects]
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87 21:04:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138596; Wed 13-May-87 00:02:53 EDT
Date: Wed, 13 May 87 00:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [RAM: exiting from unwind protects]
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301313646.BABYL@C.CS.CMU.EDU>
Message-ID: <870513000235.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 10 May 1987 14:54 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I find the following pretty persuasive...
I don't. Actually it seems to be mostly irrelevant to the issue at
hand. Here's some commentary on it. Feel free to show this to RAM if
you wish.
Date: Saturday, 2 May 1987 11:16-EDT
From: Rob MacLachlan <RAM>
I don't really agree with Moon about this thing. I certainly knew about
about the feature of being about to write something that you can't exit
from using any common lisp facility, but I don't see this as a
"serious environment bug". Our system has always has this property.
When someone first pointed out this property of Common Lisp way back
when, I did in fact write the pathological example and it did in fact
behave in the pathological fashion. After a while I got bored of
trying to throw out of the break loop, and I quit.
If I had really been doing anything, I could always have skipped over
the losing frame using debug-return. Environment problems can have
environment solutions.
I don't know what debug-return is (presumably something in the Spice
Lisp environment). Unless it's something that bypasses unwind-protect
and deliberately doesn't evaluate the cleanup forms, I don't think it
solves the problem. However, I agree that environment problems can have
environment solutions, and I think the issue is to make sure that the
language doesn't forbid the environment from solving this by trying to
enforce a particular semantics for the pathological construct, instead
of having it be an error.
In any case, I could have saved work I was
doing from the break loop. This feature certainly isn't a big deal;
there are lots of ways a malicious Lisp user can blow the system out
of the water. What happened the last time you did
(makunbound '*terminal-io*)?
The second paragraph on p.329 appears to say that it is invalid for a
portable program to do that. What I am arguing for is a similar
restriction on portable programs doing the similar thing with
unwind-protect and throw. So I think this example actually supports my
position.
In contrast, it seems to me that all the "fixes" for this problem
result in substantial increases in the complexity of the language
defintion for no gain. It seems that Moon has already introduced
three new things into the language:
1] The concept of "throwing out of an unwind protect cleanup". When
are you in an unwind protect? What does it mean to throw out of
it? Does this apply to lexical exits too? Does this signal an
error?
(block block
(unwind-protect <foo>
(return-from block)))
Does this?
(unwind-protect <foo>
(block block
(return-from block)))
Most of this would be answered by re-reading the relevant proposal to
the cleanup committee (are these archived someplace public?), which
was not written by me. I agree that we need a better-written version
of that proposal that is easier to understand and less ambiguous. The
one I am looking at is
Message-ID: <870227172152.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Edit history: Revision 1 by KMP 02/27/87
My only contribution to the discussion was
in the message <870423020745.9.MOON@EUPHRATES.SCRC.Symbolics.COM>.
Here are some relevant excerpts from the referenced proposal:
If a non-local return is done while in the cleanup form of an
UNWIND-PROTECT, the behavior is not always well-defined.
There are three basic cases:
...
1. Transfer to a point inside the point to which control
would have transferred.
and what I proposed in answer to this was to do one of three
things in case 1, transfer to a point inside the point to
which control would have transferred.
1. wimp out and say it "is an error"
2. signal an error
3. resume the original throw, just as if the cleanup handler had
exited normally.
I prefer signalling an error, because I firmly believe that the program
is ill-formed.
Note that I have not introduced any new concepts here. I don't think
the UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT proposal introduced new
concepts either; it just made explicit reference to concepts that
were already in Common Lisp. The argument that these concepts make
the language definition too complex seems to be an argument that the
language definition should not attempt to define the semantics of throwing
precisely.
2] The concept of errors that aren't errors, which we need so that
users can't screw themselves with this feature no matter how hard
they try.
Last time I read the "error proposal" it included this concept. I don't
think I invented it, I just borrowed it from there while writing up the
discussion of throw vs. unwind-protect. Certainly in the absence of the
error proposal this concept is not introduced into the language, since the
language currently does not contain an IGNORE-ERRORS construct, nor any
other construct that is sensitive to the issue.
3] The implicit requirement that an implementation have some exit
mechanism other than throw so that it can unwind out of cleanup
forms even if the user can't. What does the system do when you
are running in an unwind protect and the user types an interrupt?
In fact, it seems that Moon is being inconsistent here, since he
has already assumed that interrupts do throw. If the user
interrupts when running in a cleanup do you signal an error, and
then signal an error whenever the user tries to abort out of the
debugger?
All of point 3 appears to be a misunderstanding of what was being
discussed and proposed. "Transfer to a point inside the point to which
control would have transferred" is irrelevant to "the user types an
interrupt" (which I take to mean something like Maclisp's control-X
and control-G, i.e. abort the program and return to a read-eval-print
loop) since those would be transfers to a point outside of, or equal to,
any throw currently in progress.
If I had ever been screwed by this, I would think differently.
The inside-Symbolics component of this discussion originated with a
customer being screwed by this.
I'm
sure that most of the reason that this problem doesn't happen is that
people usually don't write code that aborts from unwind protect
cleanups. There is a big difference between saying that something is
rarely needed and possibly dangerous and saying that it must signal an
error.
I am convinced that the simplest evaluation model is to say that the
unwind-protect cleanup is evaluated in the lexical and dynamic
environment of the unwind-protect form.
Nobody ever proposed anything different as far as I am aware.
Any alternative must somehow
introduce an "in an unwind protect cleanup" marker into the dynamic
environment of the cleanup forms.
The issue is actually what happens you nest throws (throughout this
discussion "throw" has been understood to include all non-local exits,
not only the THROW function). Thus the marker in question is "in throw",
not "in an unwind protect cleanup".
Yes, the dynamic state of a program that is throwing would need to
include an indication of where it was throwing to if we were to adopt
the proposal that misnested throws signal an error or the proposal that
they resume the outer throw. In the "is an error" case, there are no
requirements on the implementation, and the requirement is only that
portable programs cannot assume any particular behavior. However, I
can't imagine an implementation of throw that does -not- remember in its
dynamic state where it's going to throw to when it finishes evaluating
some unwind-protect cleanup forms.
To get back to earth after all this lofty flaming, remember that the
specific case mentioned in the UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
proposal was
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
and the question is: what does the THROW to BAR do? One possible answer
that many people seemed to favor is it throws to BAR and the throw to
FOO never happens. The answer I prefer is that this is not a valid
Common Lisp program. Does this make the issue clear?
∂12-May-87 2124 Moon@STONY-BROOK.SCRC.Symbolics.COM SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87 21:24:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138606; Wed 13-May-87 00:23:14 EDT
Date: Wed, 13 May 87 00:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870428141313.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870513002305.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Observation: some of the discussion appears to be assuming that
someone is proposing that
(position 3 #2a((0 1 2)(3 4 5))) => (1 0)
As far as I can tell no one is proposing that. My reading of
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE (by Touretzky)
is that it proposes
(position 3 #2a((0 1 2)(3 4 5))) => 3
and the other two options propose that it remains an error.
Vote: I mildly favor SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED as
being the least confusing to users, although either of the other two
proposals would be okay with me: if there is strong support for them,
I won't expend energy resisting it.
∂13-May-87 0012 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: FUNCTION-TYPE (version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87 00:12:36 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138655; Wed 13-May-87 03:10:55 EDT
Date: Wed, 13 May 87 03:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-ID: <870513031041.0.KMP@TSUKUBA.SCRC.Symbolics.COM>
While I'm sympathetic to this proposal in some form, I can't support
it as currently drafted.
My main problem is that it tries to clarify too many things. The question of
what is a function is logically distinct from that of what may go in the
function cell. I am very excited about clarifying the type issues, but very
nervous about changing what can go in the function cell.
Here are my notes on the proposal...
* I'd like to see the word COMPILED-CLOSURE struck. It adds nothing to
the meaning and could provoke useless debate about what the difference
might be between a function and a closure; currently CL has no such
formal distinction.
* It seems to me that we might as well go ahead and create types
INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
the FUNCTION type and the COMPILED-FUNCTION-P predicate already implements
this distinction. Perhaps eventually COMPILED-FUNCTION-P could be flushed.
* "behavior" is spelled "behvior" in one place.
* I never realized that FUNCTIONP and (TYPEP x 'FUNCTION) were not
synonymous. Please cite a page reference that suggests they are allowed
to differ. I could not find a definition of the FUNCTION type specifier
when I looked just now.
* In item 3 of proposal, I'd say "the text of their description" to be
completely clear. To me, the descriptions are the abstract entities
which you've just noted don't need change.
* Items 4 & 5 are a major incompatibility that I would like to see proposed
and discussed separately so as not to bog down the type issues which this
proposal should be about. Macsyma, for example, makes considerable use
of symbols and lambda expressions in the function cell. Making sure it
would be happy with this clause would be very non-trivial.
For now, I would leave this essentially as you left APPLY, pending a
separate proposal to change that; i.e., FUNCTION and SYMBOL-FUNCTION can
return things which are non-functions if those objects can be coerced to
functions. SETF of SYMBOL-FUNCTION can accept such a coercible object,
and the value later retrieved will be the given object (not a coerced
form of it), though obviously internally some encapsulation may want to
go on for stock hardware to make function calling fast.
* At the in-person meeting at Xerox in March, I suggested that COMPILE
should not complain if it gets an already-compiled thing, and someone
pointed out that this could be bad because some users might be wanting
recompilation and others might want no action. I think we should consider
a better fix, like something that lets the user say explicitly what
action to take if the function is already compiled, but for now I would
leave this an error.
* The adoption cost does not mention STEP, TRACE, and ED. I think it should.
* The benefits section should flush the reference to Lisp1, since the only
criterion for being a Lisp-1 is that you have a unified namespace. In
fact, this is not properly related to that and mentioning Lisp1 may
provoke unnecessary worry. It is adequate to say it makes things more
like Scheme.
* I believe the conversion cost is potentially much greater than you
have estimated unless you move items 4 & 5 to another proposal.
The ability to say (SETF #'FOO 'BAR) rather than (SETF #'FOO #'BAR) has
important consequences to do with the inheritance of new definitions of
BAR if it is later defined. I think that some people exploit this a lot
and it may not always be easy to detect.
The impact on home-grown steppers, trace and advise facilities, and other
functions which manipulate the contents of the function cell has also been
underplayed.
Please don't let these comments get you down. It's clear that a lot of work
has gone into this and I'm hopeful that it will be resolved successfully.
I just want to keep the decision process as unencumbered as possible and
right now it's just too hard for me to reason clearly about the overall
impact of such a sweeping proposal.
-kmp
∂13-May-87 0914 RPG FUNCTION-TYPE and Archives
To: cl-cleanup@SAIL.STANFORD.EDU
First, the archives for CL-cleanup are in clclea.msg[com,lsp].
However, this archive was separated out from the main Common-Lisp
archive only recently.
Second, about the FUNCTION-TYPE proposal: I support it, but mildly.
I favor a much stronger change, and this proposal is just barely above
the level of acceptability to me.
KMP wonders
`` I never realized that FUNCTIONP and (TYPEP x 'FUNCTION) were not
synonymous. Please cite a page reference that suggests they are allowed
to differ. I could not find a definition of the FUNCTION type specifier
when I looked just now.''
The suggestion is on the same pages that allows the following two to
differ:
(let ((x '(or to-be (not to-be))))
(assert `(is-a question ,x)))
``To be or not to be: That is the question.''
KMP's third sentence is the answer: FUNCTION is a type name symbol
that corresponds to no type, and therefore (typep x 'function) is
not defined. This is what this proposal attempts to remedy.
However, to be slightly more serious, I am disturbed to always read
that Common Lisp must do this, that, or the other thing because otherwise
the effort to keep Macsyma up to date will suffer, or that the reason that
some feature must continue to exist is because it is reflected in
Macsyma usage. I like Macsyma as well as the next guy, but not enough to
kill a language to keep its code legal.
-rpg-
∂13-May-87 1133 @ALLEGHENY.SCRC.Symbolics.COM:File-Server@QUABBIN.SCRC.Symbolics.COM FUNCTION-TYPE, archives, and Macsyma
Received: from [192.10.41.45] by SAIL.STANFORD.EDU with TCP; 13 May 87 11:33:01 PDT
Date: Wed, 13 May 87 14:23 EDT
From: KMP@QUABBIN.SCRC.Symbolics.COM
Sender: File-Server@QUABBIN.SCRC.Symbolics.COM
Subject: FUNCTION-TYPE, archives, and Macsyma
To: RPG@SAIL.STANFORD.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870513142303.6.FILE-SERVER@ALLEGHENY.SCRC.Symbolics.COM>
I spent well over a year converting Macsyma to what I believe is a good
faith reading of CLtL. At the outset, I was as tired as anyone of its
odd little needs that were unwritten parts of various languages and that
had to be supported only out of fear of breaking Macsyma.
I am trying to invoke no such fear now. Indeed, I don't even work for the
Macsyma project any more. I am sure that those who do work for it are
willing to do reasonable work to upgrade Macsyma into the next generation
Lisp.
However, those people (whoever they may be when it finally happens; my
grandchildren, I fear) will need to be able to adequately estimae the
impact of the various changes which we have made. And we ourselves must
adequately estimate the impact so that we can know how much work we are
asking people to absorb.
I said several times in my message that I might be willing to go along
with this change. I am not trying to "kill a language" as you put it.
I just want us to be honest. And when I read the text in this proposal
that said "... attempts to minimize the impact on user code ... the
only impact should be a change in the operation of certain type predicates
... relatively easy to find and fix" I knew we were not being honest.
The changes we're proposing may be good ones. They will not all be easy
to find and fix.
I do think that the part which simply involves types is fairly
non-controversial. I would like to see it separated so we can agree that
it is and leave a smaller issue to worry about.
∂13-May-87 1626 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE and Archives
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87 16:25:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 139430; Wed 13-May-87 19:24:13 EDT
Date: Wed, 13 May 87 19:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE and Archives
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 13 May 87 12:14 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <870513192404.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 13 May 87 0914 PDT
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
First, the archives for CL-cleanup are in clclea.msg[com,lsp].
However, this archive was separated out from the main Common-Lisp
archive only recently.
[Second part deleted]
This is very useful, but if this was in answer to my question of yesterday
about archiving, I was actually asking a different question. I was wondering
if the current versions of the various proposals are archived somewhere,
such that one could retrieve a single proposal without first wading through
a bunch of mail. This might be a directory with each proposal in a separate
file, for example.
∂13-May-87 2121 edsel!bhopal!jonl@navajo.stanford.edu looping in unwind-protect cleanups
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 May 87 21:21:16 PDT
Received: by navajo.stanford.edu; Wed, 13 May 87 21:18:45 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01380; Wed, 13 May 87 20:01:41 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03441; Wed, 13 May 87 20:03:04 PDT
Date: Wed, 13 May 87 20:03:04 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705140303.AA03441@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 13 May 87 00:02 EDT <870513000235.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
Subject: looping in unwind-protect cleanups
I tend to agree with you that looping caused by UWP cleanup forms throwing
back through the same cleanup forms is a serious error; and that this
situation not only ought to be "signalled" as an error, but also ought to
be recuperable (from the debugger, I suppose). However, one or two loose
ends need to be cleared up. You mention the example from the original
proposal:
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
and you use the phrase "... this is not a valid Common Lisp program."
I have trouble with that characterization, since it seems to imply
some mechanically checkable property of programs. The "serious error"
mentioned above is a dynamic condition, which could be caused by other
programs that are not so clearly analyzable. For example, consider just
removing the (THROW 'BAR 4) out of the lexical context:
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(DO-A-BIT-OF-WORK)
(PRINT 'XXX))))
(DEFUN DO-A-BIT-OF-WORK ()
(UNLESS (WINNINGP)
(THROW 'BAR 4)))
I think you see how this could be extended to produce an example that could
not be mechanically proven invalid by the UWP-non-local-exit criterion,
even though it would get into the disastrous loop.
How about this characterization of the problem: for a given process, the
unwind-protect cleanup forms should be viewed as non-reentrant code. An
attempt to execute such code reentrantly will signal an error, which will
probably enter the debugger (and entering the debugger won't, by itself,
cause another throw, so there is no fear of infinite looping from this
step). In such a case, the user should have the choice of continuing with
the re-entrant invocation, or of doing an "abort" which skips doing the
signalled UWP frame's cleanups. In the first case, he may want to "try
again" at the cleanups, because it just might be that they were entered
"re-entrantly" only because he interrupted in the middle of some cleanups,
and then asked the debugger to "abort to toplevel"; or maybe entering the
"embrace" depends on some global data which he has just "fixed". In the
second case, he may recognize the "deadly embrace" as hopeless, and simply
wish to punt out of it.
There is some concern about "hairing up" the UWP/THROW mechanisms. I
don't believe that this approach, or *** ones like it *** (which were
alluded to in previous messages) is really all that complex.
Implementationally, it would seem to require at most:
(1) For each UWP frame, the "cleanup forms" have an associated lock
(possibly a per-process lock) that is acquired upon entry [and
released upon exit?]. Failure to acquire the lock signals the
re-entrancy error. The acquisition/release time could hardly
be more than a few memory cycles time, and hence won't be a serious
slowdown for THROWing.
(2) The low-level part of THROW would admit a "skip me" argument, so
that it could be told which UWP/CATCH frame to omit the cleanups
on [but not the lock releasings?]. Only one "skip me" is needed,
since nested "deadly embraces" could be undone one step at a time.
[In fact there really only could be one frame to "skip" -- the one
whose lock is already tied up.]
I don't mean to imply that this is the only, or the best, or even the
clearest implementation of such an idea; but I claim that non-re-entrancy
isn't all that deep a concept here. It's more to the point than saying
"non-interruptible" (which is wrong); and more succinct than some other
characterizations of how one might detect the "deadly embrace".
-- JonL --
∂13-May-87 2158 Moon@STONY-BROOK.SCRC.Symbolics.COM looping in unwind-protect cleanups
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87 21:58:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 139634; Thu 14-May-87 00:57:23 EDT
Date: Thu, 14 May 87 00:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: looping in unwind-protect cleanups
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8705140303.AA03441@bhopal.edsel.uucp>
Message-ID: <870514005708.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 13 May 87 20:03:04 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
...you use the phrase "... this is not a valid Common Lisp program."
I have trouble with that characterization, since it seems to imply
some mechanically checkable property of programs.
I didn't mean to imply that.
...I think you see how this could be extended to produce an example that could
not be mechanically proven invalid by the UWP-non-local-exit criterion,
even though it would get into the disastrous loop.
Sure. If you give me a few hours, I will mail you examples of programs
in Common Lisp, Ada, and Basic the determination of whose validity in
their respective languages is equivalent to the halting problem. The
basic plan is to write a program where it cannot be mechanically proven
whether an array subscript is out of bounds.
....Implementationally, it would seem to require at most:
(1) For each UWP frame, the "cleanup forms" have an associated lock ....
This is rather overcomplicated, so let me tell you how the versions of
Symbolics systems that implement my proposed checking do it. None of
these are released yet. This is from memory, I didn't write the code.
1. Every catch (including ones generated internally by tagbody and block
when nonlocal exits via go, return, or return-from are happening) contains
a validity bit, which is initially 1.
2. When throw plans to throw past a catch, it sets its validity bit to 0.
This happens after throw finds the target catch (since Common Lisp says if
there is no matching catch, the error is signalled in the dynamic environment
of the throw), and before throw starts removing state from the stack and
evaluating cleanup forms. Here throw includes nonlocal go, return, and
return-from along with certain debugger commands.
3. An attempt to throw to a catch whose validity bit is 0 signals an error
that isn't caught by IGNORE-ERRORS.
4. The error in 3 is implemented by the Common Lisp function BREAK.
5. When throw evaluates an unwind-protect cleanup form, it first removes
it from the list of such forms, so that if you throw again it won't be
evaluated again. (I'm pretty sure that a close reading of CLtL shows
that this is required.)
Note that the only data structure or dynamic state is one bit per catch,
the only overhead is in throw, and the error signalling is implemented
with an existing Common Lisp facility.
∂14-May-87 1039 edsel!bhopal!jonl@navajo.stanford.edu looping in unwind-protect cleanups
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 10:39:24 PDT
Received: by navajo.stanford.edu; Thu, 14 May 87 10:36:48 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA03537; Thu, 14 May 87 10:23:10 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA03960; Thu, 14 May 87 10:24:36 PDT
Date: Thu, 14 May 87 10:24:36 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705141724.AA03960@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 14 May 87 00:57 EDT <870514005708.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: looping in unwind-protect cleanups
Re: . . . let me tell you how the versions of
Symbolics systems that implement my proposed checking do it. None of
these are released yet. This is from memory, I didn't write the code.
. . .
Note that the only data structure or dynamic state is one bit per catch,
the only overhead is in throw, and the error signalling is implemented
with an existing Common Lisp facility.
A lock is effectively 1 bit per catch, and by storeing it in the catch
frame, it is process-specific; lock-acquisition would be done in THROW,
and is very low overhead. I suspect these two proposed implementations
are isomorphic at a fundamental level, with your "validity bit" replaceing
my "lock".
The only thing that seems a bit peculiar in your review of the new Symbolics
code is that the error signalled by "failure to acquire the lock" has to be
treated specially (not caught by IGNORE-ERRORS, goes directly to BREAK,
"does not pass GO, lands in jail", whatever). Maybe that is the reason RAM
and some others were so upset by the original proposal. I think I see the
point of the special handling; but I don't like the singularity.
-- JonL --
∂14-May-87 1046 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-SYMBOL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87 10:45:08 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 140100; Thu 14-May-87 13:43:48 EDT
Date: Thu, 14 May 87 13:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870514134332.1.KMP@TSUKUBA.SCRC.Symbolics.COM>
I support PATHNAME-SYMBOL:NO, but I have the following comments:
* Please change the reference to filename "nil" to filename "NIL"
since (STRING NIL) returns "NIL" and not "nil". This is a minor
point, but I think worth doing.
* Note that the biggest impact of this change on users is that
they will not be able to say (LOAD'FOO) which they commonly type
interactively to mean (LOAD "FOO"). One advantage, of course, is
that in case-sensitive file systems, people won't do
(load'foo) and wonder why file "FOO" (rather than "foo") is not
found. Still, I think the fact that we're going to make it an
error for people to type (LOAD 'FOO) is worth documenting as part
of the cost of this proposal so that no one ends up surprised.
∂14-May-87 1051 KMP@STONY-BROOK.SCRC.Symbolics.COM Issue: PATHNAME-STREAM
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87 10:50:32 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 140111; Thu 14-May-87 13:49:01 EDT
Date: Thu, 14 May 87 13:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870514134846.2.KMP@TSUKUBA.SCRC.Symbolics.COM>
I support PATHNAME-STREAM:FILES-ONLY.
Since string-streams are non-file streams that CL programmers
will be familiar with, it might be worth mentioning them explicitly
in the proposal as an example of something for which the indicated
functions do not have to work.
∂15-May-87 2144 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 May 87 21:44:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 141562; Sat 16-May-87 00:44:03 EDT
Date: Sat, 16 May 87 00:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <192342.870428.JAR@AI.AI.MIT.EDU>,
<870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<870428-220403-2039@Xerox>,
<870429093550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<192793.870429.JAR@AI.AI.MIT.EDU>,
<8704292330.AA13102@bhopal.edsel.com>,
<870429222608.2.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<193127.870429.JAR@AI.AI.MIT.EDU>,
<8704300644.AA13625@bhopal.edsel.com>,
<8704302311.AA01123@bhopal.edsel.com>,
<193809.870430.JAR@AI.AI.MIT.EDU>,
<8705012012.AA00639@bhopal.edsel.uucp>,
<FAHLMAN.12299231012.BABYL@C.CS.CMU.EDU>,
<194629.870502.JAR@AI.AI.MIT.EDU>,
<FAHLMAN.12299293460.BABYL@C.CS.CMU.EDU>
Message-ID: <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I finally found the time to read this huge pile of mail carefully and think
clearly about it. Here's my considered opinion, but before telling you
which proposal I support I'd like to clear away some underbrush. I
apologize for the 200 line length, but I can't make all the concepts
unambiguously clear with a briefer speech.
We speak of cells, which are conceptual locations that remember a value and
can be read and written. Sometimes these conceptual locations are
implemented by actual memory locations, and sometimes they aren't, but
that's an implementation detail and is irrelevant here. (Sometimes these
are called variables, but other times the word "variable" means something
else, so for the sake of clarity I'm not going to use the word "variable".)
Right now, Common Lisp has two kinds of cells: global cells and local
cells. Local cells have lexical extent, while global cells have global
extent and can be referenced from anywhere except where they are shadowed
by a local cell referenced by the same name.
Right now, Common Lisp has two kinds of binding: Lexical binding creates a
new local cell. Special binding saves the value of a global cell, gives it
a new value during the extent of the binding, and later restores the old
value. We know that special binding saves and restores because of what
other functions see when they read the cell. Please don't get confused
with issues of shallow-bound versus deep-bound implementation, which are
irrelevant here: I said cells are not the same thing as memory locations.
Note that I am carefully using different words for the two kinds of cells
from the words for the two kinds of binding; lack of differentiation here
has led to a lot of confusion, I think.
Right now, Common Lisp has a fairly complicated set of rules for how to
determine what cell is referenced when a program mentions a variable name.
(When I say "lexically free", I mean outside of all bindings of that name,
regardless of whether those bindings are special or lexical.)
1. If the reference is lexically free, use the global cell.
2. Otherwise, in the absence of a SPECIAL declaration use the cell that
was affected by the innermost binding; if that binding was special,
use the global cell; if it was lexical, use the local cell created
by that binding.
3. Otherwise, the SPECIAL declaration forces use of the global cell.
We certainly do not want to introduce a third kind of cell, because that
would lead to a great deal of confusion. Nor do we want to introduce a
third kind of binding. What we -are- trying to accomplish is to make the
primitive concepts orthogonally available. An example of a problem we have
right now that needs to be fixed is that there is no way to say that a name
is not misspelled without simultaneously saying that bindings of that name
should be special rather than lexical. These concepts should be available
as separate constructs.
There are four things that we would like to be able to proclaim about
a variable name (aside from TYPE):
- the default kind of binding if no declaration specifies which kind
- the name is not misspelled so don't warn about free references
- it is illegal to specially bind the global cell, because it is
a constant or because we want to optimize the performance of a
deep-binding implementation
- it is illegal to store into the global cell, because it is a constant
It is already possible in Common Lisp to proclaim all four of these things,
but some of them are mixed up with other concepts and not separately
available. Let's pick names for the four kinds of proclamations, and let's
also agree that any proclamation serves the "not misspelled" purpose. Let's
further agree that these four proclamations are mutually exclusive.
LEXICAL -- does nothing other than "not misspelled"
SPECIAL -- changes the default kind of binding from lexical to special
GLOBAL -- makes it illegal to specially bind the global cell
CONSTANT -- makes it illegal to store into the global cell
CONSTANT implies GLOBAL because special-binding is storing
SPECIAL exists now. LEXICAL is Rees's proposal. CONSTANT exists now
but only buried inside the DEFCONSTANT macro. GLOBAL exists now but
only when implied by DEFCONSTANT. I propose to make CONSTANT and
GLOBAL explicitly available.
It appears to be appropriate to make CONSTANT and GLOBAL proclamations
change the default kind of binding to "illegal", rather than leaving
it lexical.
Now we have to ask what these proclamations mean as declarations.
Let us agree that they have the same scoping rules as the SPECIAL
declaration, i.e. they can be attached to a binding and they can
also be wrapped around references, which they pervasively affect
until shadowed by the next declaration or binding.
LEXICAL attached to a binding forces the binding to be lexical even
if there is a SPECIAL, GLOBAL, or CONSTANT proclamation. LEXICAL
shadows the effect of a special binding on references; therefore we
must add another rule to the "complicated set":
4. Otherwise, a LEXICAL declaration forces use of the local cell
created by the innermost lexical binding of the name, or if there
is none, use of the global cell.
SPECIAL means the same as it has always meant in Common Lisp.
GLOBAL or CONSTANT attached to a binding makes the binding illegal.
GLOBAL or CONSTANT affects a reference by forcing it to use the global
cell, thus rule 3 in the "complicated set" must be modified to treat GLOBAL
and CONSTANT the same as SPECIAL. We could also just make GLOBAL and
CONSTANT illegal as declarations. Another idea would be to make CONSTANT
as a declaration allow you to create a new lexical constant. I'm going to
take the path of least addition to the language and make them illegal.
Note that PROCLAIM-LEXICAL:RESTRICTED conflates LEXICAL and GLOBAL, which
seems undesirable to me. We want to make each primitive concept separately
available.
Okay, so which proposal do I support? Well, I support a slight modification
of PROCLAIM-LEXICAL:GENERAL, which I will now explicate (text mostly
copied from Rees):
Proposal (PROCLAIM-LEXICAL:GENERAL+GLOBAL):
Introduce new declaration specifiers, LEXICAL, GLOBAL, and CONSTANT, which
are mutually exclusive with the SPECIAL declaration specifier. All four
may be used as proclamations; only SPECIAL and LEXICAL may be used as
declarations.
A name may be proclaimed only one of LEXICAL, SPECIAL, GLOBAL, or
CONSTANT. A name is said to be unproclaimed if it has not been
proclaimed to be any of these four.
A free reference or assignment to a name is an error if it is
unproclaimed and undeclared.
A LAMBDA-binding in the absence of a declaration or proclamation binds
the lexical variable.
SPECIAL proclamations and declarations behave as defined in CLtL.
LEXICAL proclamations have no effect other than to make the name
cease to be unproclaimed. LEXICAL declarations shadow all enclosing
declarations and proclamation of any of these four types. LEXICAL
declarations have the same scoping rules as SPECIAL declarations.
GLOBAL proclamations make it an error to bind the name.
CONSTANT proclamations make it an error to bind the name and an
error to assign to the name.
DEFCONSTANT is defined in terms of SETQ and the CONSTANT proclamation.
All keyword symbols are automatically proclaimed CONSTANT.
A free reference or assignment accesses the same value regardless
of the declaration or proclamation. This is called the global value.
SPECIAL binding alters the global value within its extent.
(Multiple process and multiple processor systems will have to make
their own definitions of the extent of a SPECIAL binding, as noted
on p.38 of CLtL--this proposal is not a proposal to standardize that.)
The preceding paragraph should be understood carefully. There is only
one global value for a name and it is used by all free references, all
free assignments, and all SPECIAL bindings.
Example:
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 4 (5 4))
Note that the second element of the list is different from
the value, 2, it would have in PROCLAIM-LEXICAL:GENERAL.
That is because the special binding of y changes the global
value to 4, and the declared-lexical reference to y accesses
the global value, since there is no surrounding lexical binding.
Cost of adopting change:
I believe this is the same as current practice as specified by CLtL,
except that all of the primitive concepts have been made visible instead
of being hidden inside other concepts. Compilers and interpreters
will need to support LEXICAL as a declaration.
Referencing or assigning to an unproclaimed and undeclared name
"is an error", not "signals an error", which allows but does not
require an implementation to issue a warning. This is a change from
current language but does not mandate a change from current practice.
Benefits:
LEXICAL proclamation enhances compatibility with Scheme.
GLOBAL proclamation allows more efficient deep-bound implementations
and enhances compatibility with Interlisp and VMLISP.
Cost of converting existing code:
None, it's upward compatible.
Aesthetics:
The "insidious and disgusting aspect" doesn't get any worse. Making
primitive concepts explicitly available can only enhance aesthetics.
Discussion:
Let's hear it!
∂16-May-87 0302 edsel!bhopal!jonl@navajo.stanford.edu Issue: PROCLAIM-LEXICAL
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 May 87 03:02:07 PDT
Received: by navajo.stanford.edu; Sat, 16 May 87 02:58:25 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA10964; Sat, 16 May 87 01:33:58 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
id AA09180; Sat, 16 May 87 01:35:27 PDT
Date: Sat, 16 May 87 01:35:27 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705160835.AA09180@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 16 May 87 00:43 EDT <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
Your summary of the "proclamation" issue is excellent. It delineates all
the separate issues very well, and also it incorporates all the points I
have made in previous notes about these matters. So I for one would be
quite happy to see your revised proposal accepted.
-- JonL --
∂17-May-87 1447 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87 14:47:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 17:46:49-EDT
Date: Sun, 17 May 1987 17:46 EDT
Message-ID: <FAHLMAN.12303180096.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 16 May 1987 00:43-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I think that Moon's analysis of this issue is right on the mark, and I
like his proposal except for two points:
First, it is made clear that only one of SPECIAL, LEXICAL, GLOBAL, or
DYNAMIC can be in effect for a variable at any one time, but the
proposal does not address the question of whether you can over-ride an
old proclamation in this set by issuing a new one. We have to address
that, I think, and it is a moderately complex question.
It seems to me that we want to allow a variable to be re-proclaimed for
two reasons: to correct proclmations issued in error by the user,
without having to kill off the Lisp and start over, and to make it
easier to merge programs written by two different programmers. (The
latter reason may be bogus -- these guys shouldn't be in the same
package anyway -- but there are times when a quick-and-dirty fix is
extremely handy.) On that other hand, we want the compiler to be able
to wire certain things in tight as a result of these proclamations, so
we need to make clear that if you proclaim something to be GLOBAL,
compile some code, then proclaim it to be SPECIAL and then compile some
more code the rebinds this variable, you may not get what you expect.
Same with unconstantifying a constant.
If Rob's compiler proposal, or something like it, were in effect, we
could probably explain what the rules are within that framework.
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable. The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
And yet, when the compiler comes across an undeclared variable, I want
to get a warning, especially now that I can use a LEXICAL proclamation
to flush that warning with no other side effects.
I think that the right move is to say that accessing and referencing an
undeclared variable is legal, and that such references access the global
cell while leaving the variable in unproclaimed state. We should then
encourage (require?) compiler writers to issue a warning in such cases.
Of course, if you believe that the compiler has no business warning
about anything that is technically legal (and some wording in Moon's
"cost of adoption" section suggests to me that he may be in this camp),
then the above proposal is a non-sequitur. In my view, however, the
compiler may issue a warning about code that is legal but suspicious,
though I agree with Rees that in all such cases there should be
something you can put in a program to say, "Shut up, I know what I'm
doing here." The LEXICAL proclamation gives us that.
-- Scott
∂17-May-87 1931 FAHLMAN@C.CS.CMU.EDU Issue: FUNCTION-TYPE (version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87 19:31:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:30:44-EDT
Date: Sun, 17 May 1987 22:30 EDT
Message-ID: <FAHLMAN.12303231779.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Cc: fahlman@C.CS.CMU.EDU
Subject: Issue: FUNCTION-TYPE (version 3)
In-reply-to: Msg of 13 May 1987 03:10-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
In reply to: Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>.
My main problem is that it tries to clarify too many things.
I agree with Moon that Compile can be split out of this proposal and
dealt with separately. However, I feel that the other issues really
have to be dealt with all at once. The issue of what constitutes the
FUNCTION type and whether function definitions have to be functions in
whatever sense we define are closely interconnected. We'll ahve to
solve the latter issue sooner or later, so let's try to do it now.
* I'd like to see the word COMPILED-CLOSURE struck. It adds nothing to
the meaning and could provoke useless debate about what the difference
might be between a function and a closure; currently CL has no such
formal distinction.
No problem with eliminating any mention of this. It was just a "for
instance" anyway.
* It seems to me that we might as well go ahead and create types
INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
the FUNCTION type and the COMPILED-FUNCTION-P predicate already implements
this distinction. Perhaps eventually COMPILED-FUNCTION-P could be flushed.
One possibility is not to define any of these and to eliminate
COMPILED-FUNCTION-P. That's what I proposed in version 3. The other
possibility is to define COMPILED-FUNCTION and INTERPRETED-FUNCTION as
subtypes of FUNCTION, but then we have to spell out what happens in
implementations that have only one internal representation or that have
more than two -- raw interpreted, transformed, and fully compiled, for
example. Then there's the question of whether closures are, or can be,
a separate subtype. In some sense, all true functions are closures,
since to get one you close a lambda expression in some lexical
environment. However, we might want to reserve the word "closure" for
functions that actually capture some part of the lexical context outside
the function itself, and to create CLOSURE types based on this idea.
In my view, we are better off avoiding this whole thing and leaving it
to the individual implementations.
* In item 3 of proposal, I'd say "the text of their description" to be
completely clear. To me, the descriptions are the abstract entities
which you've just noted don't need change.
I disagree with this use of "description", but there's no point in
arguing epistemology here. I'll change the wording.
Macsyma, for example, makes considerable use
of symbols and lambda expressions in the function cell. Making sure it
would be happy with this clause would be very non-trivial.
I don't understand this. If your code expects to put random symbols and
lambda lists into function cells and to get them back later, unchanged,
this is not portable Common Lisp. At least, the manual is so vague in
this area that you'd better not count on anything of this sort being
portable. PCL was storing symbols in symbol-function cells for awhile,
but this broke lots of implementations and they finally gave up on this.
For now, I would leave this essentially as you left APPLY, pending a
separate proposal to change that; i.e., FUNCTION and SYMBOL-FUNCTION can
return things which are non-functions if those objects can be coerced to
functions. SETF of SYMBOL-FUNCTION can accept such a coercible object,
and the value later retrieved will be the given object (not a coerced
form of it), though obviously internally some encapsulation may want to
go on for stock hardware to make function calling fast.
I know of several Common Lisps in which this is not the status quo. So
either way we clarify this, it is an incompatible change for someone. I
hate to see us take a step backwards here, just to make Macsyma more
portable than it currently is.
I agree that we should make a bit more of this issue in the "conversion
costs" section -- truth in advertising -- but I think that saying that a
function definition must be a function is an important part of the
rationalization we are trying to achieve.
Would it make life any easier for Macsyma (and other programs with this
same problem, if any exist) if we were to add a function that extracts
the lambda expression from a function if the function is uncompiled and
is not a closure (in the stronger sense mentioned above)? In some
implementations this might be EQ or at least EQUAL to the original
Lambda, but in others it might have been macro-expanded or altered in
some way that preserves its essential behavior. We could call the
function EXTRACT-LAMBDA-EXPRESSION or something like that.
* At the in-person meeting at Xerox in March, I suggested that COMPILE
should not complain if it gets an already-compiled thing, and someone
pointed out that this could be bad because some users might be wanting
recompilation and others might want no action. I think we should consider
a better fix, like something that lets the user say explicitly what
action to take if the function is already compiled, but for now I would
leave this an error.
How about if we just adopt your earlier proposal: if the function is
already compiled, COMPILE is a no-op that returns the NAME.
* The adoption cost does not mention STEP, TRACE, and ED. I think
it should.
OK.
* The benefits section should flush the reference to Lisp1, since the only
criterion for being a Lisp-1 is that you have a unified namespace. In
fact, this is not properly related to that and mentioning Lisp1 may
provoke unnecessary worry. It is adequate to say it makes things more
like Scheme.
OK.
* I believe the conversion cost is potentially much greater than you
have estimated unless you move items 4 & 5 to another proposal.
The ability to say (SETF #'FOO 'BAR) rather than (SETF #'FOO #'BAR) has
important consequences to do with the inheritance of new definitions of
BAR if it is later defined. I think that some people exploit this a lot
and it may not always be easy to detect.
The impact on home-grown steppers, trace and advise facilities, and other
functions which manipulate the contents of the function cell has also been
underplayed.
Well, as I said, such code is currently not portable because nothing in
the book unambiguously requires that symbols and lambda expressions be
put into the SYMBOL-FUNCTION cell unchanged (or that such changes be
undone upon retrieval), and because many implementations currently do
not do this. So there's a cost either way we clarify this. Doing it
the way you suggest tends to put the burden on implementors rather than
on the maintainers of old code, but I still think it is a step
backwards.
-- Scott
∂17-May-87 1944 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE and Archives
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87 19:42:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:42:14-EDT
Date: Sun, 17 May 1987 22:42 EDT
Message-ID: <FAHLMAN.12303233875.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION-TYPE and Archives
In-reply-to: Msg of 13 May 1987 12:14-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
In reply to: Dick Gabriel <RPG at SAIL.STANFORD.EDU>.
Second, about the FUNCTION-TYPE proposal: I support it, but mildly.
I favor a much stronger change, and this proposal is just barely above
the level of acceptability to me.
I assume that the "stronger proposal" you favor would require FUNCALL,
APPLY, and friends to accept only true functions.
I would go along with putting both options into the proposal we send to
X3J13 and let them vote on it. My guess is that the conservatives would
prevail, but I personally would favor the "stronger proposal". (That's
easy for me, because I have relatively little code to maintain.) It
might be worth a try -- maybe truth and beauty would win.
However, there's a chance that if we put forward two options, the whole
thing will bog down for a while. I wonder if it is worth the risk of
added delay.
-- Scott
∂18-May-87 1344 gls@Think.COM Issue: PROCLAIM-LEXICAL
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 18 May 87 13:44:21 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 18 May 87 16:46:47 EDT
Date: Mon, 18 May 87 16:44 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870518164427.1.GLS@BOETHIUS.THINK.COM>
I am in agreement with everything Moon has said, except for the
following paragraph:
Right now, Common Lisp has two kinds of cells: global cells and local
cells. Local cells have lexical extent, while global cells have global
extent and can be referenced from anywhere except where they are shadowed
by a local cell referenced by the same name.
I believe this paragraph confuses the notions of extent and scope.
In the terminology of CLTL chapter 3, both kinds of cell have
indefinite extent (but the bindings of a global cell have dynamic
extent). The *names* used to refer to these cells have lexical
and <???> scope, respectively.
If this bit of language were to be cleaned up, I would favor something
like Moon's proposal.
--Guy
∂18-May-87 1529 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87 15:29:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 142936; Mon 18-May-87 18:28:46 EDT
Date: Mon, 18 May 87 18:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <870518164427.1.GLS@BOETHIUS.THINK.COM>
Message-ID: <870518182849.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 18 May 87 16:44 EDT
From: Guy Steele <gls@Think.COM>
I am in agreement with everything Moon has said, except for the
following paragraph:
Right now, Common Lisp has two kinds of cells: global cells and local
cells. Local cells have lexical extent, while global cells have global
extent and can be referenced from anywhere except where they are shadowed
by a local cell referenced by the same name.
I believe this paragraph confuses the notions of extent and scope.
Quite right. I must have meant to say "scope", but spazzed.
∂19-May-87 1316 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-NEGATIVE-PARAMETERS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 13:16:02 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 143993; Tue 19-May-87 16:15:07 EDT
Date: Tue, 19 May 87 16:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-NEGATIVE-PARAMETERS
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12303677629.BABYL@C.CS.CMU.EDU>
Message-ID: <870519161434.8.KMP@TSUKUBA.SCRC.Symbolics.COM>
[Removed Berman, Common-Lisp; added CL-Cleanup]
Date: Tue, 19 May 1987 15:19 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Date: 19 May 1987 14:38-EDT
From: Richard Berman <berman at vaxa.isi.edu>
... do you know what this should do?
(FORMAT NIL "~-1%")
... there seem to be a number of places in the format directives where
negative numbers would make no sense. I don't think that all of these
are explicitly flagged. This should probably be fixed up in the
standard, but until then it seems reasonable to assume non-negative
integers unless there's some obvious meaning for the negative case.
This would be a reasonable topic for us to address in CL-Cleanup.
I agree that a reasonable approach for the interim, and in fact in the
next edition of the manual, is to say that format parameters are assumed
to be non-negative integers except as specifically stated. Of course, we'll
need to specify clearly whether signalling an error or assuming 0 or whatever
is the right thing otherwise, and that should perhaps be done by someone who
has surveyed all the ops to determine the likely impact on typical code of
assuming 0, etc.
Cases where some implementations signal an error and others quietly ignore
the error are what drive developers of portable code nuts.
By the way, I note that this case is most important where the user has
written ~V%, since it's not statically detectable in that case that a problem
has arisen.
Obviously, someone should write this up as a formal proposal. I've picked
the issue name FORMAT-NEGATIVE-PARAMETERS above and this message can be used
to seed the proposal when someone has time to write it.
∂19-May-87 1739 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 17:39:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144321; Tue 19-May-87 20:38:25 EDT
Date: Tue, 19 May 87 20:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12303180096.BABYL@C.CS.CMU.EDU>
Message-ID: <870519203829.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 17 May 1987 17:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think I forgot to answer this, but if you're seeing it twice, I apologize.
I think that Moon's analysis of this issue is right on the mark, and I
like his proposal
Thanks.
except for two points:
First, it is made clear that only one of SPECIAL, LEXICAL, GLOBAL, or
DYNAMIC
CONSTANT, you mean.
can be in effect for a variable at any one time, but the
proposal does not address the question of whether you can over-ride an
old proclamation in this set by issuing a new one. We have to address
that, I think, and it is a moderately complex question.
I think this is an environment issue rather than a language issue.
....
If Rob's compiler proposal, or something like it, were in effect, we
could probably explain what the rules are within that framework.
I think Rob's proposal would only tell us how to compile a program that
proclaims a variable one way inside a Lisp that proclaims it another way,
but not what happens when the result of that compilation is loaded into
that Lisp.
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
In other words, it's an environment issue. I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable.
Actually I just copied that from Rees.
The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human users?
And yet, when the compiler comes across an undeclared variable, I want
to get a warning, especially now that I can use a LEXICAL proclamation
to flush that warning with no other side effects.
I think that the right move is to say that accessing and referencing an
undeclared variable is legal, and that such references access the global
cell while leaving the variable in unproclaimed state. We should then
encourage (require?) compiler writers to issue a warning in such cases.
That would be okay with me, however people in general might prefer that we
just say it's an error and not try to dictate what the compiler should do.
I have no strong opinion here.
Of course, if you believe that the compiler has no business warning
about anything that is technically legal (and some wording in Moon's
"cost of adoption" section suggests to me that he may be in this camp),
then the above proposal is a non-sequitur. In my view, however, the
compiler may issue a warning about code that is legal but suspicious,
though I agree with Rees that in all such cases there should be
something you can put in a program to say, "Shut up, I know what I'm
doing here." The LEXICAL proclamation gives us that.
True.
∂19-May-87 1801 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 18:01:09 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 19 May 87 21:00:27-EDT
Date: Tue, 19 May 1987 21:00 EDT
Message-ID: <FAHLMAN.12303739600.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 19 May 1987 20:38-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
In reply to: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
In other words, it's an environment issue. I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).
OK, I think we agree here, more or less. I'd like to see some
indication in the proposal that this particular "is an error" is one
that many interpreters might choose to allow for the convenience of
programmers. Some people equate "is an error" with "don't do it" rather
than "don't depend on it across implementations".
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable. The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human
users?
Well, you're right in saying that "is an error" would be the right thing
if our only concern were portable programs. That's our main concern,
but not our only one. I would still like to be able to do a few typical
interpreter things in any Common Lisp, and this is one of them. So I am
strongly opposed to any proposal that says it is OK for (setq foo 27)
this issue doesn't affect portable
programs, but that's not the only concern we should deal with. I would
like to see
And yet, when the compiler comes across an undeclared variable, I want
to get a warning, especially now that I can use a LEXICAL proclamation
to flush that warning with no other side effects.
I think that the right move is to say that accessing and referencing an
undeclared variable is legal, and that such references access the global
cell while leaving the variable in unproclaimed state. We should then
encourage (require?) compiler writers to issue a warning in such cases.
That would be okay with me, however people in general might prefer that we
just say it's an error and not try to dictate what the compiler should do.
I have no strong opinion here.
Of course, if you believe that the compiler has no business warning
about anything that is technically legal (and some wording in Moon's
"cost of adoption" section suggests to me that he may be in this camp),
then the above proposal is a non-sequitur. In my view, however, the
compiler may issue a warning about code that is legal but suspicious,
though I agree with Rees that in all such cases there should be
something you can put in a program to say, "Shut up, I know what I'm
doing here." The LEXICAL proclamation gives us that.
True.
∂19-May-87 1812 FAHLMAN@C.CS.CMU.EDU Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 18:12:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 19 May 87 21:11:08-EDT
Date: Tue, 19 May 1987 21:10 EDT
Message-ID: <FAHLMAN.12303741560.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
Sorry, I hit the wrong key and shot that last message off before I was
done editing...
In reply to: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.
In other words, it's an environment issue. I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).
OK, I think we agree that "is an error" would be the best thing here.
I'd like to see some indication in the proposal (maybe down in the
discussion part) that this particular "is an error" is one that some
interpreters might choose to tolerate (preferably with some warning) for
the convenience of interactive users. Some people equate "is an error"
with "don't do it" rather than "don't depend on it in portable code".
The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable. The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human
users?
Well, you're right in saying that "is an error" would be the right thing
if our ONLY concern were portable programs. That's our main concern,
but not our only one. I would still like to be able to do a few typical
interpreter things in any legal Common Lisp, and this is one of those
things. So I am strongly opposed to any proposal that says it is OK for
(setq foo 27) not to work in some Common Lisp interpreters.
So I feel pretty strongly that my earlier formulation was the
best one: references and assignments of undeclared/unproclaimed
variables refer to the global cell, but leave the variable undeclared.
And compilers are allowed (not required) to warn about such references.
-- Scott